與AWS

兼容複製緩存解決方案

我的使用情況如下：與AWS

我們有大約500臺服務器自動縮放EC2集羣中運行需要訪問相同的配置數據（以鍵/值的方式奠定了）幾每秒百萬次。

配置數據不是很大（1或2 GB），並且變化不大（在高峯時間每分鐘更新/刪除/插入數十個）。

延遲對我們至關重要，所以數據需要在運行我們的應用程序的每個實例上覆制並保存在內存中。

最終的一致性很好。但是，我們需要確保每次更新都會在某個時間點傳播。（知道服務器可以隨時關機）跨服務器的更新傳播應該可靠並且易於設置（我們不能爲我們的服務器配置靜態IP地址，或者我們不希望走「僞造」的路線「多播的AWS等）

下面是我們在過去探討了解決方案：

使用普通的Java地圖和使用我們的定製系統來傳播跨集羣更新。（顯然，它不能很好地擴展）
使用EhCache及其複製功能。但是在EC2上設置它非常痛苦，並且不可靠。

下面是我們正在考慮的嘗試的解決方案：

阿帕奇點燃（https://ignite.apache.org/）對複製的策略。
Hazelcast的複製地圖功能。（http://docs.hazelcast.org/docs/latest/manual/html-single/index.html#replicated-map）
每個應用程序節點上的Apache Geode。（http://geode.apache.org/）

我想知道這些解決方案是否可以用於我們的用例。最終，我可能會面臨每個問題。

這是我迄今發現：

Hazelcast的複製地圖是某種最近，仍然有點靠不住（異步更新可能會丟失的情況下，縮小的）
看起來的Geode成爲「（儘管它自2000年代初開始就在開發中）
Ignite看起來可能很適合，但我不太確定如果我們繼續添加/定期移除節點。

謝謝！

來源

2017-02-14 Maxime

Geode是Gemfire的開源版本。 Gemfire已經存在了很長一段時間了。當你正在進行研究的時候，搜索Gemfire相關的討論可能也是有幫助的，因爲Gemfire和Geode的基礎知識基本相同。 –

Geode應該爲你的用例工作。您應該能夠在每個節點上使用Geode複製區域。您可以選擇執行同步或異步複製。如果發生故障，複製區域會從系統中的現有成員獲取數據的初始副本，同時確保沒有任何正在進行的操作丟失。

就配置而言，您必須啓動一對/幾個成員發現過程（Geode定位器）並將每個成員指向這些定位器。（我們建議您啓動一個定位器/ AZ並使用3個AZ來防止網絡分區）。

Geode/GemFire已經穩定了一段時間;印度和中國的鐵路公司在很長一段時間內爲其預訂系統提供低延遲高可擴展性要求。

披露：我是Geode的提交者。

來源

2017-02-15 00:36:12 Swapnil

如果我選擇同步複製，是否必須等到更新傳播到500臺服務器？或者只是確保它至少在一臺/兩臺/三臺服務器上覆制？您還提到發現使用發現過程發生。它是否也適用於AWS地區？ – Maxime

我建議Swapnil的解決方案以及CQRS架構模式通過最終的一致性來處理您的更新。幾年前，我在GentFire的幫助下，在Vaughn的書「Implementing Domain-Driven Design」中提供了這個解決方案。您的數百萬讀取/秒來自您節點上的只讀羣集，並針對讀取進行了優化。較小的羣集適用於您的寫入，並針對您的寫入聚合進行了優化。 Geode的自然保證異步事件機制將更新傳遞到您的讀取羣集進行更新。 Geode在保證異步事件和CQ方面具有優勢。 –

至於發現過程，是的，只要IP可見，它就可以跨AWS區域使用。定位器具有高擴展性，易於管理和防止裂腦。 Geode將保證複製品使用不同的AZ來保證一致性。如果您的區域之間的延遲很高，那麼您可以選擇Geode的WAN網關來保證更新。 WAN Gateway幾乎每一家美國的主要銀行都在使用多年來進行復制。請參閱https://geode.apache.org/docs/guide/topologies_and_comm/multi_site_configuration/multisite_topologies.html –

Ignite爲S3存儲上的發現提供本地AWS集成：https://apacheignite-mix.readme.io/docs/amazon-aws。它解決了主要問題 - 重新啓動實例時不需要更改配置。簡而言之，任何成功加入拓撲的節點都會將其座標寫入存儲桶（並在失敗或離開時刪除它們）。當你啓動一個新節點時，它讀取這個桶並連接到一個列出的地址。

來源

2017-02-15 00:44:49

Hazelcast的複製地圖不適合您的使用案例。請注意，它是跨所有節點而不是客戶機節點/服務器複製的映射。另外，如你所說，它還不完全可靠。
這裏是Hazelcast溶液：

創建與一組這取決於數據的大小節點的Hazelcast羣集。
創建一個分佈式映射（IMap）並根據鍵/值對的大小/數量調整驅逐配置的數量&。數據被分割到所有節點上。
設置基於數據的重要性以及從實際源（數據庫/文件）中提取數據需要多少時間進行備份計數。分佈式地圖默認有1個備份。
在客戶端，設置NearCache並將其附加到分佈式映射。這個NearCache將把Key/Value對保存在本地/客戶端本身中。所以get操作最終會以毫秒爲單位。

需要考慮的事情有NearCache解決方案：

第一個GET操作會比較慢，因爲它要經過網絡從集羣獲取數據。
緩存失效並不完全可靠，因爲會延遲與羣集同步並可能會結束讀取陳舊的數據。同樣，在所有緩存解決方案中，情況也是如此。
客戶端有責任設置Nearcache條目的超時和無效。所以未來的拉動會從集羣中獲得新的數據。這取決於數據刷新或值被替換爲密鑰的頻率。

來源

2017-02-17 07:38:21

回答

相關問題