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