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