首先，我通常会同意 AirThomas 的所有建议。如果可以的话，缓存东西通常是好的，但我发现它有点脆弱，因为这非常依赖于你的应用程序是什么。数据压缩是另一个非常可靠的建议，但我对这两个方面的印象是，你所看到的加速将是相对微不足道的。可能高达 2-5 倍，但如果它们比这更快，我会感到非常惊讶。

假设纯 I/O（写入/读取内存）不是您的限制因素（如果是，您可能不会变得更快），我会为zeromq做一个强大的插件。用创作者的话来说：

我们拿了一个普通的 TCP 插座，注入了从苏联秘密原子研究项目偷来的放射性同位素混合物，用 1950 年代的宇宙射线轰炸它，然后把它送到一个吸毒成瘾的漫画书作者手中， -伪装的恋物癖，用于穿着氨纶的鼓胀肌肉。是的，ØMQ 套接字是网络世界的拯救世界的超级英雄。

虽然这可能有点戏剧化，但zeromq在我看来，套接字是计算机网络世界几年来最令人惊叹的软件之一。我不确定你现在使用什么来传递消息，但是如果你使用传统的东西rabbitmq，你可能会看到多个数量级的加速（个人注意到大约 500 倍，但取决于很多建筑）

在此处查看一些基本基准。

如果您期望（或发现）节点不止一次地请求相同的数据，也许您可​​以从缓存策略中受益？尤其是在某些数据的使用频率比其他数据高得多的情况下，您可以只定位最常用的信息。

如果数据是可变的，您还需要一种方法来确认自上次请求以来它没有更改，这比重复请求更便宜。

如果每个节点都有自己的单独缓存，这会更加复杂。根据您的系统和任务的性质，您可以考虑添加一个专门用于在处理节点之间提供信息的节点，并在该节点上构建单个缓存。

例如，当这可能是一个好主意时，假设我通过低带宽连接从远程数据存储中检索一些数据，并且我有一些需要该数据的任务，这些数据专门分布在本地节点之间。我绝对不希望每个节点通过该低带宽连接单独请求信息，而另一个节点之前可能已经请求过。由于我的本地 I/O 比通过低带宽连接的 I/O 便宜得多，我可能会在处理节点和充当中间服务器的远程源之间添加一个节点。该节点将接收来自处理节点的请求，与远程数据存储进行通信，并缓存频繁请求的数据，以最大限度地减少对低带宽连接的使用。

这里可能适用于您的具体情况的核心概念是：

• 消除或减少冗余 I/O；
• 利用内存使用和计算时间之间的权衡；
• 并非所有 I/O 都是平等的。