大家好，我是楼仔呀。
这篇文章对 Zookeeper 的注册中心原理再深化钻研一下，关键学习它的设计思维。
间接上文章目录：
1. 基本概念
1.1 什么是注册中心？
注册中心关键有三种角色：
最后，RPC Client 从本地缓存的服务节点列表中，基于负载平衡算法选用一台 RPC Sever 动员调用。
1.2 注册中心须要成功性能
依据注册中心原理的形容，注册中心必定成功以下性能，偷个懒，间接贴幅图：
2. ZK 注册中心原理
Zookeeper 可以充任一个服务注册表（Service Registry），让多个服务提供者构成一个集群，让服务消费者经过服务注册表失掉详细的服务访问地址（Ip + 端口）去访问详细的服务提供者。
2.1 ZK 注册流程
每当一个服务提供者部署后都要将自己的服务注册到 Zookeeper 的某一门路上: /{service}/{version}/{ip:port} 。
比如咱们的 HelloWorldService 部署到两台机器，那么 Zookeeper 上就会创立两条目录：
在 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 地址列表发送给服务消费者机器”，这步是如何成功的呢？
这个疑问也是经典的消费者-消费者疑问，处置的形式有两种：
Zookeeper 经常使用的是“颁布-订阅形式”，这里就要提到 Zookeeper 的 Watch 机制，全体流程如下：
上方讲的有点形象，大文言解读一下，Zookeeper 的 Watch 机制其实就是一种推拉联合的形式：
3. ZK 能否适宜作为注册中心
讨论这个疑问前，咱们必定须要知道什么是 CAP 通常。
3.1 CAP 通常
CAP 通常是散布式架构中关键通常：
关于 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 最终分歧性，可以和我一同讨论哈。