redis - Chronicle Map vs Redis vs Koloboke

Question

我们有一个系统，其中在 50 个服务器上使用相同的数据集(键值对)。此数据集的更新次数约为每小时 1000 次，必须在这 50 台服务器上进行复制。我们有一个主系统接收这些更新并负责将这些更新传播到其他服务器。目前，我们每小时以文件的形式将整个数据集(而不是增量更新)同步到所有服务器。然后将此数据加载到不可变的 Koloboke map 中。每个服务器每秒处理大约 25000 个请求，每个请求对该 map 进行 30 次查找。在这些服务器上收到的请求的平均响应延迟最多必须在 3 毫秒左右，因此内存中的 koloboke map 可以很好地帮助我们维持这个响应时间。

但是，我们当前跨服务器同步此数据的系统会导致问题:

1) 大多数情况下，此关键数据的同步在其中一台服务器上失败，导致收入损失

2) 由于此数据存储在内存中，因此它不是持久的，我们需要在每次服务器重新启动或每小时更新时重新加载此数据，这会影响应用程序的启动时间。

为了提高效率，我探索了 Koloboke 库中的 Redis、Chronicle Maps 和 Mutable maps。但是我遇到了所有这些限制:

Redis:Redis 支持复制和持久化。但是，在使用其基准测试实用程序时，我发现它可以支持的查找次数仅略高于我们的平均用例(0.8-110 万请求与 75 万，这是我们每秒的查找次数)。此外，对 redis 的调用将通过网络进行，这将损害我们 3 毫秒的平均响应时间。

Chronicle Maps:在进一步探索时，我发现 Chronicle Maps 支持复制、持久化，并且每秒可以处理多达 3000 万个请求。乍一看它似乎是一个不错的选择，但后来我发现它们不能很好地与多图一起使用，我们在我们的应用程序中生成了它们。此外，它们将数据存储在堆外，因此数据反序列化的成本会导致性能下降。

Koloboke:它的性能很好，服务于我们的用例，但不支持复制和持久化。

我找不到任何支持我们所有用例的东西。我正在寻找来自这个社区的建议，这些建议可以帮助我们有效地构建这个系统而不会对性能产生任何严重影响。对此的任何帮助将不胜感激!谢谢!

Answer 1

这个用例可以在 Aerospike 中轻松处理。 Aerospike 可以配置为完全按照您运行这些服务器的方式运行。当您对服务器集群进行任何一次更新时，Aerospike 将为您更新所有服务器。乍一看，您的读取延迟要求对于 Aerospike 也是合理的。此外，Aerospike 可以同时为您提供来自 RAM 的数据 store在 SSD 或 HDD 上以实现持久性。看起来像是为 Aerospike 量身定做的外壳。您可以使用 Aerospike Community Edition 免费运行概念验证。或者如果你想做一个 Enterprise Edition试用许可证 3 个月，并有 Aerospike 解决方案架构团队帮助您，联系 Aerospike 销售人员。要成功做到这一点，您必须针对数据容量和数据延迟正确设置 Aerospike 集群。如果配置错误，您可能会立即放弃适合您的解决方案。