hazelcast其中一個很重要的應用就是可以将多個應用伺服器組成一個分布式環境的應用，形成一個cluster。這個cluster可以選舉出一個master來對外工作。而cluster中的各台伺服器之間有資料同步機制和資料備份機制，來避免因為單個節點挂掉而導緻資料丢失和cluster的失效。資料存儲在分布式記憶體中，hazelcast可以保證資料在各個節點的均勻分布，可以增加節點和減少節點，而這個過程中，hazelcast會自動遷移資料，來保證資料的高可用。
在hazelcast中，master是指叢集裡面的主節點。這個主節點負責的是向其他成員節點更新最新的成員清單。
一開始還沒有節點，第一個啟動的節點會先尋找其他節點，這裡會根據配置的尋找機制，如果是multicast，就用multicast的方式尋找。如果是TCP/IP,就用TCP/IP的方式尋找。 找不到，就選舉自己為master。
後面加入的節點，會向已存在cluster的master發出join請求，master檢測是否符合叢集的加入要求，如果符合，就會發送最新的成員清單給新加入的成員。同時更新叢集中的資料，保證資料的均勻分布和備援。
叢集中的每個成員都有相同的成員清單。成員清單是按加入的順序排好的。如果master 挂掉了，那麼剩下的成員會收到通知，然後從成員清單中選舉下一個作為master。
在可擴充的動态分區存儲系統中，無論是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 會很溫柔地遷移一些資料到這些新的節點，最終資料均勻存儲。
Operation是hazelcast裡面操作邏輯的封裝。操作的邏輯要放在run方法裡面，類似于runnable。
首先當 ClientClusterServiceImpl啟動之後就産生一個一直監聽節點存活情況的線程[cluster-listener]。
那麼假設在執行 mapCustomers.put(1, “Joe”);操作前，其要操作的實際節點挂了，這時[cluster-listener]線程會立即感覺并更新虛拟節點表。 如果在更新完畢後操作才送出請求，則操作可以成功，如果在更新未完成時發出了請求，則會抛出異常。而這個更新虛拟節點表的過程需要幾秒鐘。在這幾秒鐘裡對失效節點的操作就真的失敗了。
用戶端向 Hazelcast寫入資料本體所在節點是必須同步的；而備份過程預設是同步的，也可以修改配置成異步。 為了保證一緻性，預設情況下，讀取資料總是從資料的owner節點讀取，這個也可以修改配置成允許從備份節點讀資料，這樣能帶來更好的讀性能。
舉例來說， 要更新key為1的資料時，由一緻性hash算法得知其存在節點A上，則對節點A發起update請求，這時如果你用另一個用戶端也要更新節點A上的key1時，這兩個操作肯定是同步控制的。而節點A把key1備份到節點B的過程也可以配成同步，然後再配成允許從備份節點讀取，這樣保證了一緻性和高可讀。如果備份過程配成異步，再配成不允許從備份節點讀取，則保證了高可寫，而一緻性也基本ok，隻是萬一異步備份未完成時，資料本體所在節點挂掉，那就可能産生髒資料。
========廣告時間========
<a href="http://blog.csdn.net/wangyangzhizhou/article/details/74080321">為什麼寫《Tomcat核心設計剖析》</a>
=========================
歡迎關注：