我们有一个系统,在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:它的性能很好,可以满足我们的使用需求,但不支持复制和持久性.
我找不到任何支持我们所有用例的东西.我正在寻找这个社区的建议,这些建议可以帮助我们有效地构建这个系统,而不会对性能产生任何严重影 任何有关这方面的帮助将非常感谢!谢谢!