分佈式技術 -- 五、ZooKeeper配置文件分析，集羣主從選舉機制，節點類型講解

    本章節博客開始深刻下zookeeper的配置文件分析，集羣主從選舉機制，節點類型講解等內容。

 

    一塊兒學習，一塊兒進步。繼續沉澱，慢慢強大。但願這文章對您有幫助。如有寫的很差的地方，歡迎評論給建議！

    初寫博客不久，我是楊展浩。這是個人第七篇博客。加油！！！

 

一、zookeeper的配置文件分析

    配置文件內容很少，貼圖完事：

    

 

二、集羣主從選舉機制

    zookeeper的集羣與redis集羣概念很相似。zookeeper的集羣用 Leader領導者、Follower跟隨者來標識。Redis的集羣使用Master主、Slave歷來標識。

選舉機制：初次進來的zookeeper服務，在參與選舉中優先投本身一票，當發現本身的票數沒超過集羣的半數以上的時候，就會投出另外一票給當前集羣中的id最大的那一個zookeeper服務，zookeeper服務一次開啓加入集羣，當有一個zookeeper服務獲得的投票數超過集羣的半數以上，該zookeeper服務就當選Leader領導者了，然後面加入的zookeeper服務就算id大也不能當選Leader領導者，遵循先到先得原則，由於前面已經選出了一個Leader了，除非前面當選得Leader（zookeeper服務）掛了，選舉從新開始。

    

 

三、節點類型講解

• 持久(Persistent) ：客戶端和服務器端斷開鏈接後，建立的節點不刪除。
  • 客戶端與Zookeeper斷開鏈接後，該節點依舊存在。
  • 持久化順序編號目錄節點客戶端與Zookeeper斷開鏈接後，該節點依舊存在，只是Zookeeper給 該節點名稱進行順序編號。

 

• 短暫(Ephemeral) ：客戶端和服務器端斷開鏈接後，建立的節點本身刪除。
  • 客戶端與Zookeeper斷開鏈接後，該節點被刪除。
  • 臨時順序編號目錄節點客戶端與Zookeeper斷開鏈接後，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號。

 

四、zookeeper客戶端監聽器原理

• 先要存在一個 main 線程。

• 在 main 線程中建立Zookeeper客戶端，這時就會建立兩個線程，一個負責網絡鏈接通訊（connect），一個負責監聽（listener ）。

• 經過 connect 線程將註冊的監聽事件發送給Zookeeper服務。

• 在Zookeeper服務的註冊監聽器列表中將註冊的監聽事件添加到列表中。

• Zookeeper服務監聽到列表中有數據或路徑發生變化，就會將這個消息發送給 listener 線程。

• listener線程內部調用了process()方法（就是程序員自定義的處理代碼）。

    常見的監聽例子：

• 監聽節點數據的變化    get path [watch]

• 監聽子節點增減的變化    Is path [watch]

 

五、寫數據流程