zookeeper不適合用做註冊中心的簡單總結

引用：http://jm.taobao.org/2018/06/13/%E5%81%9A%E6%9C%8D%E5%8A%A1%E5%8F%91%E7%8E%B0%EF%BC%9F/

1. 當註冊中心的服務規模超過必定數量的時候，zk不能很好的工做，不能支持很高的tps和TCP長鏈接
2. zk的寫請求是否是可擴展的
3. zk提供的Service Health Check功能很弱，基於zk的session活性檢查和臨時節點監聽機制上，不能真正反應服務的健康狀態
4. zk原生客戶端沒有提供數據緩存機制，當註冊中心宕機的時候，會形成服務不可用
5. zk原生客戶端很差用，難以掌握Client/Session狀態機，zk的客戶端和服務端交互協議不簡單，好比：TCP長鏈接Session管理，Ephemeral Znode（臨時節點），Event&Notification（事件訂閱通知）,ping（心跳檢測）
6. 複雜的異常處理，ConnectionLossException和Disconnected事件

ZooKeeper應該 「The King Of Coordination for Big Data」！大數據協調之王

　　

ZAB協議（zookeeper原子廣播協議），崩潰恢復模式（羣首選舉協議，），原子廣播模式（消息廣播協議，相似於兩階段提交協議）

1. znode，分爲持久節點和臨時節點，節點都有一個是否有序的屬性。臨時節點TCP鏈接斷開後，就會被刪除。
2. 能夠設置znode的事件監聽(watch)。
3. 客戶端主要有zkclient,curator
4. 節點數據最大可設置爲1M
5. 2181默認服務端口，3888默認選舉端口，leader會監聽2888端口，follower鏈接leader
6. leader（羣首）,follower（追隨者）,observer（觀察者）
7. 獨立模式，仲裁模式（集羣模式）
8. 事務是有序的zxid64位,低32位是單調遞增的，高32表示leader的週期
9. 節點權限READ，WRITE，CREATE，DELETE，ADMIN
10. 內置鑑權模式，world，auth，digest，ip，super