我们有一个系统，其中在50台服务器上使用相同的数据集(键值对)。对该数据集的更新次数约为每小时1000次，并且必须在这50台服务器之间进行复制。我们有一个主系统，该系统接收这些更新，并负责将这些更新传播到其他服务器。当前，我们每小时以文件形式将整个数据集(而不是增量更新)同步到所有服务器。然后，将这些数据加载到不变的Koloboke映射中。每个服务器每秒处理大约25000个请求，每个请求在此映射中进行30次查找。在这些服务器上接收到的请求的平均响应等待时间最多必须达到3毫秒左右，因此内存中的koloboke映射可以很好地维持我们的响应时间。
但是，我们当前的跨服务器同步此数据的系统会导致问题:
1)大多数情况下，其中一台服务器上的关键数据同步失败，导致收入损失
2)由于此数据存储在内存中，因此不是持久性的，因此每次服务器重新启动或每小时更新一次时，我们都需要重新加载此数据，这会影响应用程序的启动时间。
为了提高效率，我在Koloboke库中浏览了Redis，编年史 map 和Mutable map 。但是我都遇到了限制:
Redis :Redis支持复制和持久性。但是，在使用其基准测试实用程序时，我发现它可以支持的查找数量仅略高于我们的平均用例(0.8-1.1百万个请求与75万个每秒的查找数)。此外，对redis的调用将通过网络进行，这会损害我们3ms的平均响应时间。
Chronicle Maps:在进一步探索这一点时，我发现Chronicle Maps支持复制，持久性，并且每秒可以处理多达3000万个请求。乍一看，这似乎是一个不错的选择，但后来我发现它们不能与多图一起很好地工作，我们在应用程序中生成了它们。而且，它们以非堆方式存储数据，因此数据反序列化的成本将导致性能下降。
Koloboke:它的性能很好，可以满足我们的用例，但不支持复制和持久性。
我找不到任何支持我们所有用例的东西。我正在从这个社区中寻求建议，这些建议可以帮助我们有效地构建此系统，而不会对性能产生任何严重影响。任何帮助，将不胜感激!谢谢!
最佳答案
这个用例可以在Aerospike中轻松处理。可以将Aerospike配置为完全运行这些服务器。当您对服务器群集进行一次更新时，Aerospike将为您更新所有服务器。乍一看，您的读取延迟要求对于Aerospike也是合理的。此外，Aerospike可以为您提供来自RAM的数据，还可以同时为SSD或HDD上的store提供数据，以实现持久性。似乎是为Aerospike量身定制的表壳。您可以使用Aerospike Community Edition免费运行概念验证。或者，如果您希望获得3个月的Enterprise Edition试用许可证并希望Aerospike解决方案架构团队为您提供帮助，请与Aerospike销售部联系。要成功完成此操作，必须正确设置Aerospike群集的数据容量和数据延迟。如果配置不当，您可能会立即放弃适用于您的解决方案。
关于redis - 纪事 map vs Redis vs Koloboke，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/45500549/