hazelcast高可用性詳解

1. Elastic Memory(彈性內存) java

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)。在此期間可能致使嚴重的操做延時。 spa

假設集羣中有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 會很溫柔地遷移一些數據到這些新的節點,最終數據均勻存儲。 內存

三、只有一份備份數據初始狀態圖 資源

相關文章
相關標籤/搜索