1. Zookeeper技术内幕
1.1. 各服务器角色介绍
1.1.1. Leader
Leader服务器是整个zookeeper集群工作机制中的核心，其主要工作有以下两个。
l 事物请求的唯一调度和处理者，保证集群事务处理的顺序性。
l 集群内部各个服务器的调度者。
请求处理链
前后一共8个处理器组成了Leader服务器的请求处理链。
1.1.2. Follower
从角色名字可以看出，Follower服务器是zookeeper集群状态的跟随者，其主要工作有以下三个。
l 处理客户端非事物请求，转发事物请求给Leader服务器。
l 参与事务请求Proposal的投票。
l 参与Leader选举投票。
和Leader服务器一样，Follower也同样使用了采用贵任链模式组装的请求处理链来处理每一个客户端请求，由于不需要负责对事物请求的投票处理，因此相对来说Follower服务器的请求处理链会简单一些。其请求处理链如下图所示。
从上图中可以看到，和Leader服务器的请求处理链最大的不同点在于，Follower服务器的第一个处理器换成了FollowerRequestProcessor处理器，同时由于不需要处理事务请求的投票，因此也没有proposalRequestProcessor处理器。
1.1.3. Observer
和Follower唯一的区别在于，Observer不参与任何形式的投票，包括事物请求Proposal的投票和Leader选举投票。简单地讲，Observer服务器只提供非事物服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事物处理能力。
1.1.4. 集群间消息通信
各个服务器之间的网络通信，都是通过不同类型的消息传递来实现的。本节中，我们围绕Zookeeper集群间的消息通信来讲解Zookeeper集群各个服务器之间是如何进行协调的。
Zookeeper的消息类型大体上可以分为四类，分别是：数据同步型、服务器初始化型、请求处理型和会话管理型。
数据同步型
数据同歩型消息是指在Learner和Leader服务器进行数据同步的时候，网络通信所用到的消息，通常有DIFF、TRUNC、SNAP和UPTODATE四种。
| 消息类型 |
发送方一接收方 |
说 明 |
| DIFF, 13 |
Leader->Learner |
用于通知Learner服务器，Leader即将与其进行DIFF方式的数据同步 |
| TRUNC, 14 |
Leader->Learner |
用于触发Learner服务器进行内存数据库的回滚操作 |
| SNAP, 15 |
Leader->Learner |
用于通知Learner服务器，Leader即将与其进行“全量” 方式的数据同步 |
| UPTODATE, 12 |
Leader->Learner |
用来告诉Learner服务器，已经完成了数据同步，可以开始对外提供服务了 |
服务器初始化型
服务器初始化型消息是指在整个集群或是某些新机器初始化的时候，Leader和Learner 之间相互通信所使用的消息类型，常见的有OBSERVERINFO、FOLLOWERINFO、 LEADERINFO、ACKEPOCH和NEWLEADER五种。
| 消悤类型 |
发送方一接收方 |
说 明 |
| OBSERVERINFO，16 |
Observer->Leader |
该信息通常是由Observer服务器在启动的时候发送给Leader的，用于向Leader服务器注册自己，同时向Leader服务器表明当前Learner服务器的角色是Observer。消息中包含了当前Observer服务器的SID 和已经处理的最新ZXID |
| FOLLOWERINFO，11 |
Follower->Leader |
该信息通常是由Follower服务器在启动的时候发送 给Leader的，用于向Leader服务器注册自己，同时向Leader服务器表明当前Learner服务器的角色是Follower消息中包含了当前Follower服务器的SID 和已经处理的最新ZXID |
| LEADERINFO, 17 |
Leader->Learner |
在上面我们已经提到，在Learner连接上Leader后， 会向Leader发送LearnerInfo消息（包含了 OBSERVERINFO和FOLLOWERINFO两类消息），Leader服务器在接收到该消息后，也会将Leader服务器的基本信息发送给这些Learner,这个消息就是LEADERINFO， 通常包含了当前Leader服务器的最新EPOCH值 |
| ACKEPOCH，18 |
Learner->Leader |
Learner在接收到Leader发来的LEADERINFO消息后，会将自已最新的ZXID和EPOCH以ACKEPOCH 消息的形式发送给Leader |
| NEWLEADER，10 |
Leader-> Learner |
该消息通常用于Leader服务器向Learner发送一个阶段性的标识消息Leader会在和Learner完成一个交互流程后，向Learner发送NEWLEADER消息， 同时带上当前Leader服务器处理的最新ZXID。这一系列交互流程包括：足够多的Follower服务器连接上 Leader或是完成数据同步 |
请求处理型
请求处理型消息是指在进行请求处理的过程中，Leader和Learner服务器之间互相通信所使用的消息，常见的REQUEST, PROPOSAL、ACK, COMMIT、INFORM 和 SYNC 六种。
| 消息类型 |
发送方—接收方 |
说 明 |
| REQUEST，1 |
Learner->Leader |
该消息是ZooKeeper的请求转发消息。在ZooKeeper中，所有的事务请求必由Leader服务器来处理。当Learner服务器接收到客户端的事务请求后，就会将请求以REQUEST消息的形式转发给 Leader服务器来处理 |
| PROPOSAL，2 |
Leader->Follower |
该消息是ZooKeeper实现ZAB算法的核心所在，即ZAB 协议中的提议。在处理事务请求的时候，Leader服务器会将事务请求以PROPOSAL消息的形式创建投票发送给集群所有的Fol lower服务器来进行事务日志的记录 |
| ACK,3 |
Follower-> Leader |
Follower服务器在接收到来自Leader的PROPOSAL消息后，会进行事务日志的记录。如果完成了事务日志的记录，那么就会以ACK消息的形式反馈给Leader |
| COMMITS |
Leader->Fol lower |
该消息用于通知集群中所有的Follower服务器，可以进行事务请求的提交了Leader服务器在接收到过半的Follower 服务器发来的ACK消息后，就进入事务请求的最终提交流程——生成COMMIT消息，告知所有的Follower服务器进行事务请求的提交 |
| INFORM，8 |
Leade->bserver |
在事务请求提交阶段，针对Follower服务器，Leader仅仅只需要发送一个COMMIT消息，Follower服务器就可以完成事务请求的提交了，因为在这之前的事务请求投票阶段，Follower已经接收过PROPOSAL消息，该消息中包含了事务请求的内容，因此Follower可以从之前的Proposal缓存中再次获取到事务请求。而对于Observer来说，由于之前没有参与事务请求的投票，因此没有该事务请求的上下文，显然， 如果Leader同样对其发送一个简单的COMMIT消息， Observer服务器是无法完成事务请求的提交的，为了解决这个问題，ZooKeeper特别设计了INFORM消息，该消息不仅能够通知Observer已经可以提交事务请求，同时还会在消息 中携带事务请求的内容 |
| SYNC，7 |
Leader->Learner |
该消息用于通知Learner服务器已经完成了 Sync操作 |
会话管理型
会话管理型消息是指ZooKeeper在进行会话管理的过程中，和Learner服务器之间互相通信所使用的消息，常见的有PING和REVALIDATE两种。
| 消息类型 |
发送方一接收方 |
说 明 |
| PING,5 |
Leader->earner |
该消息用于Leader同步Learner服务器上的客户端心跳检测，用以激活存活的客户端。ZooKeeper的客户端往往会随机地和任意一个ZooKeeper服务器保持连接，因此Leader服务器无法直接接收到所有客户端的心跳检測，需要委托给 Learner来保存这些客户端的心跳检測记录，Leader会定时地向Learner服务器发送PING消息，Learner服务器在接收到 P1NG消息后，会将这段时间内保持心跳检測的客户端列表， 同样以PING消息的形式反馈给Leader服务器，由Leader服务器来负责逐个对这些客户端进行会话激活。 |
| REVALIDATE, 6 |
Learner->Leader |
该消息用于Learner校验会话是否有效，同时也会激活会话， 这通常发生在客户端重连的过程中，新的服务器需要向Leader 发送REVALIDATE消息以确定该会话是否已经超时。 |