紀事報圖與雷迪斯與Koloboke

Question

我們有一個系統，在50臺服務器上使用相同的數據集（鍵值對）。此數據集的更新數量約爲每小時1000個，並且必須在這50個服務器上進行復制。我們有一個主系統接收這些更新並負責將這些更新傳播到其他服務器。目前，我們每個小時都以文件的形式將整個數據集（而不是增量更新）同步到所有服務器。這些數據然後被加載到不可變的Koloboke地圖中。每個服務器每秒鐘處理大約25000個請求，每個請求對這個映射進行30次查找。這些服務器上收到的請求的平均響應延遲時間最長大約爲3毫秒，因此內存中的koloboke映射可以很好地保持這種響應時間。

然而，我們目前的系統同步此數據在服務器發生問題的原因：

1）大多數往往不是，這些關鍵數據的同步上造成收入損失的一臺服務器出現故障

2）由於這些數據存儲在內存中，因此不會持久化，每次服務器重新啓動或每次每小時更新時都需要重新加載此數據，這會影響應用程序的啓動時間。

爲了提高效率，我在Koloboke圖書館探索了Redis，Chronicle Maps和Mutable地圖。但我遇到了所有這些限制：

Redis：Redis支持複製和持久性。然而，在使用其基準測試工具時，我發現它可以支持的查找次數僅略高於我們的平均用例（0.8-1.1百萬次請求vs75萬次，這是我們每秒查找的次數）。此外，通過網絡撥打redis將會影響我們的平均響應時間3ms。

編年史地圖：在進一步探索之後，我發現編年史地圖支持複製，持久性並且每秒可以處理高達3000萬的請求。起初看起來這似乎是一個不錯的選擇，但後來我發現它們不適合multimap，我們在我們的應用程序中生成這些。此外，他們存儲數據堆外，因此數據反序列化的成本會導致性能下降。

Koloboke：它的性能很好，符合我們的用例，但不支持複製和持久性。

我找不到任何支持我們所有用例的東西。我正在從這個社區尋求建議，可以幫助我們有效地構建這個系統，而不會有任何嚴重的性能影響。任何幫助，將不勝感激！謝謝！

Answer 1

這個用例可以在Aerospike中輕鬆處理。 Aerospike可以配置爲運行這些服務器的運行方式。當您對服務器羣集進行一次更新時，Aerospike會爲您更新所有服務器。乍一看，您的讀取延遲要求對Aerospike來說也是合理的。此外，Aerospike可以爲您提供RAM和同時在SSD或HDD上的數據以提供持久性。看起來像Aerospike量身定製的案例。您可以使用Aerospike Community Edition免費運行概念驗證。或者，如果您想要執行3個月的Enterprise Edition試用許可證，並且Aerospike解決方案架構團隊可以幫助您，請聯繫Aerospike銷售部門。要成功完成此操作，您必須正確設置Aerospike羣集以確保數據容量和數據延遲。如果您配置錯誤，可能會立即廢除一個適用於您的解決方案。