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集羣（https://www.cnblogs.com/wrong5566/p/6056788.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節點類型
- 臨時節點：臨時節點依賴於會話，創建臨時節點的會話結束時，臨時節點將被刪除;且臨時節點不允許擁有子節點;
- 永久節點：永久節點的生命週期不依賴於會話，可以擁有子節點;
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的應用場景：
- 數據發佈與訂閱;
- 命名服務;
- 分佈式鎖;
數據發佈與訂閱中心（配置中心）
- 發佈者將數據發佈到zookeeper中，訂閱者來獲取新的數據更新自己的配置;
- 注意點：
1. 統一管理的數據不能太大;
- 原理：
1. 所有訂閱者首次啓動時，訪問zk指定的節點獲取相關的訂閱信息;
2. 獲取數據的同時，設置對節點數據變化的監聽; zk.getData(path, true);設置對指定path的監聽
3. 被監聽的path上的節點數據發生改變時，監聽被觸發，所有對次path的訂閱者將收到zookeeperde通知，然後訪問zookeeper獲取新的配置信息;
4. 獲取數據時，再次對path設置監聽;
- 疑問：zookeeper中的數據發生改變時，zookeeper如何通知訂閱者？給訂閱者發送了什麼通知？