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