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