Zookeeper不适合做注册中心

在 CAP 模型中，zookeeper 是 CP，意味着面对网络分区时，为了保持一致性，他是不可用的。

因为 zookeeper 是一个分布式协调系统，他的核心算法是 Zab，所有设计都是为了一致性。

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原子广播协议），崩溃恢复模式（群首选举协议，），原子广播模式（消息广播协议，类似于两阶段提交协议）

  • znode，分为持久节点和临时节点，节点都有一个是否有序的属性。临时节点TCP连接断开后，就会被删除。
  • 可以设置znode的事件监听(watch)。
  • 客户端主要有zkclient,curator
  • 节点数据最大可设置为1M
  • 2181默认服务端口，3888默认选举端口，leader会监听2888端口，follower连接leader
  • leader（群首）,follower（追随者）,observer（观察者）
  • 独立模式，仲裁模式（集群模式）
  • 事务是有序的zxid64位,低32位是单调递增的，高32表示leader的周期
  • 节点权限READ，WRITE，CREATE，DELETE，ADMIN
  • 内置鉴权模式，world，auth，digest，ip，super

ZK 作为注册中心探讨

作为一个分布式协同服务，ZooKeeper 非常好，

但是对于 Service 发现服务来说就不合适了，因为对于 Service 发现服务来说就算是返回了包含不实的信息的结果也比什么都不返回要好。

所以当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。

但是 zk 会出现这样一种情况，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30 ~ 120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。

在云部署的环境下，因网络问题使得 zk 集群失去 master 节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

所以说，作为注册中心，可用性的要求要高于一致性！

在 CAP 模型中，Zookeepe 整体遵循一致性（CP）原则，即在任何时候对 Zookeeper 的访问请求能得到一致的数据结果，但是当机器下线或者宕机时，不能保证服务可用性。

那为什么 Zookeeper 不使用最终一致性（AP）模型呢？

因为这个依赖 Zookeeper 的核心算法是 ZAB，所有设计都是为了强一致性。这个对于分布式协调系统，完全没没有毛病，但是你如果将 Zookeeper为分布式协调服务所做的一致性保障，用在注册中心，或者说服务发现场景，这个其实就不合适。