bigdata - zookeeper筆記（一）

zookeeper的定義

zookeeper是分佈式應用程序的高性能協調服務，顧名思義，zookeeper用來保存分佈式應用程序的多個節點之間的狀態、配置等信息，以確保分佈式程序的正確、高速運行。

zookeeper集羣角色：leader、follower、觀察者（集羣訪問量大時，增長Observer角色）

1 客戶端訪問zookeeper時，鏈接到leader與鏈接到follower之間的區別？

• leader可處理事務操做（增刪改），且全部的事務操做只能由leader處理，其餘角色接收到事務請求時，需轉發給leader；
• follower只能處理非事務型操做（讀操做）；
• follower可參與集羣leader選舉；
• Observer功能：增長非事務型請求（讀操做）的橫向擴展性；當讀操做的需求量特別大時，可經過增減觀察者節點的方式來提升集羣性能。

2 集羣搭建

• 機器數量：zookeeper集羣選舉leader時使用posix算法，因此通常選擇奇數臺機器（2n+1）
• zookeeper集羣須要配置sun java環境（sun JDK）
• 部署leader+follower集羣（http://www.javashuo.com/article/p-tyencviy-by.html）
  • 集羣的主機間設置每臺機器的hosts
  • 修改zookeeper的配置zoo.cfg（zookeeper啓動時，若是未顯示指定配置文件，則默認讀取conf目錄下的zoo.cfg配置文件）
  • 新建myid文件
  • 配置zookeeper目錄及配置的環境變量

zookeeper數據模型

zookeeper的數據模型是樹（猜想是b+樹，但未進行確認），
1 樹上每一個節點被稱爲Znode；Znode由3部分組成：stat（znode的狀態信息）、data（znode中的數據信息）和children（znode子節點的信息）
2 節點Znode的特色：

• Znode 既能夠做爲文件存儲數據，也能夠做爲目錄；
• Znode 上的操做具備原子性；
• Znode 節點限制存放文件的大小（最大1M）；
• Znode 的訪問須要使用絕對路徑。

3 Znode節點的屬性：

• dataVersion：局部值，當前節點的數據版本；每次對當前節點設置值後，當前節點的dataVersion值都加1，默認爲0;
• cversion：局部值，當前節點的子節點版本號；子節點每次發生變化後，cversion的值都加1，默認爲0;
• cZxid：全局值，建立當前節點的事務id；每當建立一個新的znode後，cZxid的值都加1;
• mZxid：全局值，當前節點最近一次被修改的事務id；任意Znode被修改後，mzxid的值加1，其中mZxid與cZxid沒有必然的聯繫;
• pZxid：全局值，Znode子節點最近一次被建立時的cZxid;
• ephemeralOwner：局部值，記錄臨時節點的session id，若是非臨時節點，值爲0;
• dataLength：局部值，當前節點的數據長度（字節）;
• numChildren：子znode的數量;

zookeeper節點類型

1. 臨時節點：臨時節點依賴於會話，建立臨時節點的會話結束時，臨時節點將被刪除;且臨時節點不容許擁有子節點;
2. 永久節點：永久節點的生命週期不依賴於會話，能夠擁有子節點;

zookeeper shell

- jps查看zookeeper進程：QuorumPeerMain
- 鏈接zookeeper集羣：zkCli.sh -server zookeeper:2181
- 建立節點：create [-s] [-e] path data acl; -s表示順序節點、-e表示臨時節點
- 讀取節點：ls path [watch] 獲取節點的子節點、get path [watch] 獲取節點保存的數據和節點屬性信息、ls2 path [watch] 獲取節點的子節點和當前節點屬性信息
- 更新節點數據：set path data [version] 
- 刪除節點：delete path [version]、rmr path 遞歸刪除數據

zookeeper選舉機制

- 算法：FastLeaderElection
- 選舉算法用到的概念：
    服務器ID：數值型，編號越大權重越大
    選舉狀態：
        LOOKING，觀望狀態
        FOLLOWING，隨從狀態，
        OBSERVING，觀察者狀態，同步leader狀態，不參與選舉
        LEADING，領導者狀態
    數據ID：最新寫入的數據的ID
    邏輯時鐘：每輪投票，邏輯時鐘的次數相同;（根據邏輯時鐘判斷集羣中的節點是否不穩定）
- 新集羣選舉：
    1. 前提：
        1.1. 每一個機器都給本身投票;
        1.2. 投票數過半，選舉結束; 
    2. 思路：集羣中的機器啓動後，給本身投一票，而後開始與其餘機器交換投票結果，若是沒有其餘機器能夠交換，則進入LOOKING狀態；若是有其餘機器能夠交換投票，則根據服務器ID大小，服務器ID小的機器將本身的票投給服務器ID大的機器;當有一臺機器拿到過半的票數時，將結束選舉；同一集羣中，先啓動服務的機器將有更大的機會得到leader。
- 運行中的集羣選舉：
    1. 前提同上;此時選舉須要用數據ID、服務器ID、邏輯時鐘
    2. 思路：首先，同一邏輯時鐘，邏輯時鐘小的被淘汰，邏輯時鐘相同的機器將從新投票；而後，機器中數據ID大的勝出；若是數據ID相同，那麼服務器ID大的勝出。

zookeeper的應用場景：

1. 數據發佈與訂閱;
2. 命名服務;
3. 分佈式鎖;

數據發佈與訂閱中心（配置中心）

- 發佈者將數據發佈到zookeeper中，訂閱者來獲取新的數據更新本身的配置;
- 注意點：
    1. 統一管理的數據不能太大;
- 原理：
    1. 全部訂閱者首次啓動時，訪問zk指定的節點獲取相關的訂閱信息;
    2. 獲取數據的同時，設置對節點數據變化的監聽; zk.getData(path, true);設置對指定path的監聽
    3. 被監聽的path上的節點數據發生改變時，監聽被觸發，全部對次path的訂閱者將收到zookeeperde通知，而後訪問zookeeper獲取新的配置信息;
    4. 獲取數據時，再次對path設置監聽;
- 疑問：zookeeper中的數據發生改變時，zookeeper如何通知訂閱者？給訂閱者發送了什麼通知？