hazelcast高可用性詳解

1. Elastic Memory（彈性內存）

Hazelcast 默認存儲分布式數據（map entries, queue items）在可以進行GC的java heep中。由于你的heep越來越大，進行GC時可能導致你的應用暫停服務10秒，因此影響了你的應用的體驗性和響應時間。彈性內存是hazelcast使用off-heap進行存儲以避免GC時造成的暫停服務。即使你有頻繁更新TB級別的內存數據，GC時幾乎不會造成影響；從而使你的應用有可預見的延時和吞吐量。

每個map可以配置為off-heap或者on-heap這兩種存儲類型。如果map的存儲類型是off-heap,那么primary，backup和可用的near-cacheed entries 被存儲在離線堆里面，并且off-heap的存儲空間會隨著你節點數的增加而動態擴展。

彈性內存的實現不需要任何碎片整理。它的工作原理是這樣:用戶分配每個JVM幾GB的離線儲存堆，假設是40GB。Hazelcast 將創建40個DirectBuffers，每個有1GB的容量。假設有50個節點，并且要存儲2TB的數據。每個buffer被分成可配置的chunck（blocks）（一個chunck大小默認是1KB）。Hazelcast 使用可寫的blocks。例如3KB將被存儲為3個blocks。當存儲的值被移除，這些blocks被歸還到可用的blocks隊列中以便存儲其他值的時候使用。

2.Distributed Backups(分布式備份)

在可擴展的動態分區存儲系統中，無論是NoSQL數據庫、文件系統或者是內存數據網格，在集群更改時（添加或者刪除節點），在集 群重新均衡時可能導致網絡大數據傳輸。需要重新均衡這些節點中的主從數據。例如一個節點掛了，掛掉的節點的主備數據必須重新分配給其他在線的節點。以MB 數據傳輸會對集群造成消極的影響，因為要消耗機器的寶貴資源（例如網絡流量、CPU和RAM）。在此期間可能導致嚴重的操作延時。

假設集群中有50個節點，每個存儲40GB數據（20GB主數據和20GB備份數據）；假設節點5掛了，我們必須保證節點5的存 儲在集群中的臨近節點中。那么節點5到的主備數據將被分配到臨近節點7。這意味著節點7的數據量是其他節點的2倍。也意味著節點7消耗更多的CPU來處理 這兩倍請求。另外節點7必須備份這個20GB的數據到其他節點9。這對這兩個節點的負載造成極壞的一向。節點9也需要更多的內存去存儲這20GB的備份數 據。造成大量的內存浪費。

Hazelcast 解決了以上問題。一個節點的主數據均勻地被分到其他節點。也就是說每個 節點都負責備份其他節點主數據。這樣會有更好地使用內存和在減小添加或者刪除結點時對集群的影響。假設集群中有50個節點要存儲2TB的數據；每個節點存 儲20G主數據和20G備數據。假設節點3的20GB的主數據被備份到其他49個節點，每個節點有20GB/49節點3的主數據。如果節點3掛了，每個節 點有1/49它的數據；注意沒有任何數據遷移并且集群依然是均衡的！這樣的備份機制在節點掛了之后是不需要立刻重新均衡的。假設你添加了5個節點。集群中也沒有立馬均衡；因為存在的節點已經在最佳狀態。Hazelcast 會很溫柔地遷移一些數據到這些新的節點，最終數據均勻存儲。

3、只有一份備份數據初始狀態圖