我们有一个系统，其中在 50 台服务器上使用相同的数据集（键值对）。该数据集的更新次数约为每小时 1000 次，并且必须在这 50 台服务器之间进行复制。我们有一个主系统接收这些更新并负责将这些更新传播到其他服务器。目前，我们每小时以文件的形式将整个数据集（而不是增量更新）同步到所有服务器。然后将此数据加载到不可变的 Koloboke 地图中。每个服务器每秒处理大约 25000 个请求，每个请求对该映射进行 30 次查找。在这些服务器上接收到的请求的平均响应延迟必须最大约为 3 毫秒，因此内存中的 koloboke 映射可以很好地维护这个响应时间。
但是，我们当前跨服务器同步此数据的系统会导致问题：
1) 通常情况下，此关键数据的同步在其中一台服务器上失败，从而导致收入损失
2）由于这个数据是存储在内存中的，它不是持久化的，每次服务器重启或者每小时更新一次，我们都需要重新加载这个数据，这会影响应用程序的启动时间。
为了提高效率，我探索了 Koloboke 库中的 Redis、Chronicle Maps 和 Mutable maps。但是我遇到了所有这些限制：
Redis：Redis 支持复制和持久化。然而，在使用它的基准测试实用程序时，我发现它可以支持的查找数量仅略高于我们的平均用例（0.8-11 万个请求与 75 万，这是我们每秒的查找数量）。此外，对 redis 的调用将通过网络进行，这会损害我们 3 毫秒的平均响应时间。
Chronicle Maps：在进一步探索这一点时，我发现 Chronicle Maps 支持复制、持久性，并且每秒可以处理多达 3000 万个请求。乍一看，这似乎是一个不错的选择，但后来我发现它们不适用于多图，我们在应用程序中生成了它们。此外，它们在堆外存储数据，因此数据反序列化的成本会导致性能下降。
Koloboke：它的性能很好，服务于我们的用例，但不支持复制和持久化。
我找不到任何支持我们所有用例的东西。我正在寻找来自这个社区的建议，这些建议可以帮助我们有效地构建这个系统，而不会对性能产生任何严重的影响。对此的任何帮助将不胜感激！谢谢！