ZK的常用使用場景
一、註冊中心
實現方式
- 基於臨時節點
- 基於監視通知機制
注意：ZK集羣可能會掛掉，所以爲了防止zk掛掉後我們還能正常的進行服務的調用，需要在本地做一次緩存，只有當產生變化時這份緩存纔會失效
經典場景：dubbo中使用ZK做註冊中心，並且引入了服務目錄的概念，服務目錄就是本地的一個緩存，但是當服務提供者列表發生變化時會更新這個緩存列表並且重新進行服務的導入
作爲註冊中心的缺點分析
- 數據一致性的需求：zk是一個cp的系統，但是註冊中心更應該考慮a，當發生分區等問題時，只保證最終一致性即可，最終的結果只是有幾臺機器負載不均；
- 可用性：如上邊敘述，當zk發生問題時，會影響服務的正常調用，但是實踐中註冊中心不能因爲自己的原因影響服務的正常調用是註冊中心設計的指導原則
- 服務規模：zk的寫是不可擴展的，當我們的集羣節點越來越多，並且頻繁上下線的時候，會對寫節點帶來壓力
- 持久化需求：註冊中心需要關心之前的數據嗎？答案是否定的，註冊中心只需要關注當前的數據就行，所以不需要持久化本地和開啓備份
- 健康檢查：zk的健康檢查只是簡單的心跳，不能檢查服務的實際狀態
- 複雜性：zk運維成本高，需要專業的人員進行維護
參考：阿里巴巴爲什麼不用ZK作爲註冊中心
二、分佈式鎖
zk作爲分佈式鎖有兩種實現方式 都是基於臨時節點+通知機制
1.所有的節點都監聽一個臨時節點
這樣帶來的壞處是，會發生羊羣效應，如果說在這個臨時節點等待的節點超過1000個watch，那麼當臨時節點移除式就要發送1000個通知，這樣會對zk的正常讀寫帶來性能的影響。
2.改進後的分佈式鎖 引入臨時順序節點
在創建臨時節點時，創建有順序的臨時節點，後一個節點總是監聽他的前一個節點，這樣當就是一個臨時節點上只有一個監視點可以避免羊羣效應，但是也會造成按創建順序進行鎖的獲取，類似於公平鎖；
圖例
三、master選舉
基於臨時節點+同一個目錄下節點名稱不能相同
誰能創建節點成功誰是master，其他會話監聽臨時檢點狀態，當master下線後重新進行選舉
四、id生成或命名服務
基於順序節點
一個目錄下的順序節點是遞增的