大家好，我是楼仔呀。
这篇文章对 Zookeeper 的注册中心原理再深入研究一下，主要学习它的设计思想。
直接上文章目录：
1. 基本概念
1.1 什么是注册中心？
注册中心主要有三种角色：
- 服务提供者（RPC Server）：在启动时，向 Registry 注册自身服务，并向 Registry 定期发送心跳汇报存活状态。
- 服务消费者（RPC Client）：在启动时，向 Registry 订阅服务，把 Registry 返回的服务节点列表缓存在本地内存中，并与 RPC Sever 建立连接。
- 服务注册中心（Registry）：用于保存 RPC Server 的注册信息，当 RPC Server 节点发生变更时，Registry 会同步变更，RPC Client 感知后会刷新本地 内存中缓存的服务节点列表。
最后，RPC Client 从本地缓存的服务节点列表中，基于负载均衡算法选择一台 RPC Sever 发起调用。
1.2 注册中心需要实现功能
根据注册中心原理的描述，注册中心必须实现以下功能，偷个懒，直接贴幅图：
2. ZK 注册中心原理
Zookeeper 可以充当一个服务注册表（Service Registry），让多个服务提供者形成一个集群，让服务消费者通过服务注册表获取具体的服务访问地址（Ip + 端口）去访问具体的服务提供者。
2.1 ZK 注册流程
每当一个服务提供者部署后都要将自己的服务注册到 Zookeeper 的某一路径上: /{service}/{version}/{ip:port} 。
比如我们的 HelloWorldService 部署到两台机器，那么 Zookeeper 上就会创建两条目录：
- /HelloWorldService/1.0.0/100.19.20.01:16888
- /HelloWorldService/1.0.0/100.19.20.02:16888
在 Zookeeper 中，进行服务注册，实际上就是在 Zookeeper 中创建了一个 znode 节点，该节点存储了该服务的 IP、端口、调用方式(协议、序列化方式)等。
该节点承担着最重要的职责，它由服务提供者(发布服务时)创建，以供服务消费者获取节点中的信息，从而定位到服务提供者真正网络拓扑位置以及得知如何调用。
RPC 服务注册/发现过程简述如下：
服务提供者启动时，会将其服务名称，IP 地址注册到配置中心。
服务消费者在第一次调用服务时，会通过注册中心找到相应的服务的 IP地址列表，并缓存到本地，以供后续使用。当消费者调用服务时，不会再去请求注册中心，而是直接通过负载均衡算法从 IP 列表中取一个服务提供者的服务器调用服务。
当服务提供者的某台服务器宕机或下线时，相应的 IP 会从服务提供者 IP 列表中移除。同时，注册中心会将新的服务 IP 地址列表发送给服务消费者机器，缓存在消费者本机。
当某个服务的所有服务器都下线了，那么这个服务也就下线了。
同样，当服务提供者的某台服务器上线时，注册中心会将新的服务 IP 地址列表发送给服务消费者机器，缓存在消费者本机。
服务提供方可以根据服务消费者的数量来作为服务下线的依据。
2.2 ZK 的心跳检测
问题：第 3 步中“当服务提供者的某台服务器宕机或下线时”，Zookeeper 如何感知到呢？
Zookeeper 提供了“心跳检测”功能，它会定时向各个服务提供者发送一个请求（实际上建立的是一个 socket 长连接），如果长期没有响应，服务中心就认为该服务提供者已经“挂了”，并将其剔除。
比如 100.100.0.237 这台机器如果宕机了，那么 Zookeeper 上的路径就会只剩 /HelloWorldService/1.0.0/100.100.0.238:16888。
2.3 ZK 的 Watch 机制
问题：第 3 步和第 5 步中“注册中心会将新的服务 IP 地址列表发送给服务消费者机器”，这步是如何实现的呢？
这个问题也是经典的生产者-消费者问题，解决的方式有两种：
- 主动拉取策略：服务的消费者定期调用注册中心提供的服务获取接口获取最新的服务列表并更新本地缓存，经典案例就是 Eureka。
- 发布-订阅模式：服务消费者能够实时监控服务更新状态，通常采用监听器以及回调机制。
Zookeeper 使用的是“发布-订阅模式”，这里就要提到 Zookeeper 的 Watch 机制，整体流程如下：
- 客户端先向 ZooKeeper 服务端成功注册想要监听的节点状态，同时客户端本地会存储该监听器相关的信息在 WatchManager 中；
- 当 ZooKeeper 服务端监听的数据状态发生变化时，ZooKeeper 就会主动通知发送相应事件信息给相关会话客户端，客户端就会在本地响应式的回调相关 Watcher 的 Handler。
上面讲的有点抽象，大白话解读一下，Zookeeper 的 Watch 机制其实就是一种推拉结合的模式：
- 服务消费者会去监听相应路径（/HelloWorldService/1.0.0），一旦路径上的数据有任务变化（增加或减少），Zookeeper 只会发送一个事件类型和节点信息给关注的客户端，而不会包括具体的变更内容，所以事件本身是轻量级的，这就是推的部分。
- 收到变更通知的客户端需要自己去拉变更的数据，这就是拉的部分。
3. ZK 是否适合作为注册中心
探讨这个问题前，我们一定需要知道什么是 CAP 理论。
3.1 CAP 理论
CAP 理论是分布式架构中重要理论：
- 一致性(Consistency)：所有节点在同一时间具有相同的数据；
- 可用性(Availability) ：保证每个请求不管成功或者失败都有响应；
- 分隔容忍(Partition tolerance) ：系统中任意信息的丢失或失败不会影响系统的继续运作。
关于 P 的理解，我觉得是在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用，而可用性是，某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求。
CAP 不可能都取，只能取其中 2 个的原因如下：
如果 C 是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，期间可用性就会降低。
如果 A 是第一需求，那么只要有一个服务在，就能正常接受请求，但是对与返回结果变不能保证，原因是，在分布式部署的时候，数据一致的过程不可能想切线路那么快。
再如果，同时满足一致性和可用性，那么分区容错就很难保证了，也就是单点，也是分布式的基本核心。
3.2 ZK 作为注册中心探讨
作为一个分布式协同服务，ZooKeeper 非常好，但是对于 Service 发现服务来说就不合适了，因为对于 Service 发现服务来说就算是返回了包含不实的信息的结果也比什么都不返回要好。
所以当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。
但是 zk 会出现这样一种情况，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30 ~ 120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。
在云部署的环境下，因网络问题使得 zk 集群失去 master 节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
所以说，作为注册中心，可用性的要求要高于一致性！
在 CAP 模型中，Zookeepe 整体遵循一致性（CP）原则，即在任何时候对 Zookeeper 的访问请求能得到一致的数据结果，但是当机器下线或者宕机时，不能保证服务可用性。
那为什么 Zookeeper 不使用最终一致性（AP）模型呢？因为这个依赖 Zookeeper 的核心算法是 ZAB，所有设计都是为了强一致性。这个对于分布式协调系统，完全没没有毛病，但是你如果将 Zookeeper为分布式协调服务所做的一致性保障，用在注册中心，或者说服务发现场景，这个其实就不合适。
4. 小节
我们对 Zookeeper 的注册中心总结如下：
Zookeeper 的心跳检测，可以自动探测服务提供者机器的宕机或下线；
Zookeeper 的 Watch 机制，可以将变更的注册列表推给服务消费者；
Zookeeper 是 CP 模型，不太适合作为注册中心。
不过网上也有说，Zookeeper 目前已经支持 AP，准确说是 AP + Base 最终一致性，可以和我一起讨论哈。
