ZooKeeper的消息类型大体上可以分为四类，分别是：数据同步型、服务器初始化型、请求处理型和会话管理型。
数据同步型
数据同步型消息是指在Learner和Leader服务器进行数据同步的时候，网络通信所用到的消息，通常有DIFF、TRUNC、SNAP和UPTODATE四种。下表中分别对这四种消息类型进行了详细介绍。
| 消息类型 |
发送方→接收方 |
说明 |
| DIFF, 13 |
Leader→Learner |
用于通知Learner服务器、Leader即将与其进行“DIFF”方式的数据同步 |
| TRUNC，14 |
Leader→Learner |
用于触发Learner服务器进行内存数据库的回滚操作 |
| SNAP，15 |
Leader→Learner |
用于通知Learner服务器，Learner即将与其进行“全量”方式的数据同步 |
| 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中，所有的事务请i去必须由Leader服务器来处理。当Learner服务器接收到客户端的事务请求后，就会将请求以REQUEST消息的形式转发给Leader服务器来处理 |
| PROPOSAL，2 |
Leader→Follower |
该消息是ZooKeeper实现ZAB算法的核心所在，即ZAB协议中的提议。在处理事务请求的时候，Leader服务器会将事务请求以PROPOSAL消息的形式创建投票发送给集群中所有的Follower服务器来进行事务日志的记录 |
| ACK，3 |
Follower→Leader |
Follower服务器在接收到来自Leader的PROPOSAL消息后，会进行事务日志的记录。如果完成了事务日志的记录，那么就会以ACK消息的反馈给Leader。 |
| COMMIT，4 |
Leader→Follower |
该消息用于通知集群中所有的Follower服务器，可以进行事务请求的提交了。Leader服务器在接收到过半的Follower服务器发来的ACK消息后，就进入事务请求的最终提交流程——生成COMMIT消息，告知所有的Follower服务器进行事务请求的提交。 |
| INFORM，8 |
Leader→Observer |
在事务请求提交阶段，针对Follower服务器，Leader仅仅只需要发送一个COMMIT消息，Follower服务器就可以完成事务请求的提交了，因为在这之前的事务请求投票阶段，Follower已经接受过PROPOSAL消息，该消息中包含了事务请求的内存，因此Follower剋有从之前的Proposal缓存中再次获取到事务请求。而对于Observerl哎说，由于之前没有参与事务请求的投票，因此没有该事务请i去的上下文，显然，如果Leader同样对其发送一个简单地COMMIT消息，Observer服务器是无法完成事务请求的提交的。为了解决这个问题，ZooKeeper特别设计了INFORM消息，该消息不仅能够通知Observer已经可以提交事务请求，同时还会在消息中携带事务请求的内容。 |
| SYNC，7 |
Leader→Learner |
该消息用于通知Learner服务器已经完成了Sync操作 |
会话管理型
会话管理型消息是指ZooKeeper在进行会话管理的过程中，和Learner服务器之间互相通信所使用的消息，常见的有PING和REVALIDATE两种。下表中对这两种雄安喜类型进行了详细的介绍。
| 消息类型 |
发送方→接收方 |
说明 |
| PING，5 |
Leader→Learner |
该消息用于Leader同步Learner服务器上的客户端心跳检测，用以激活存活的客户端。ZooKeeper的客户端往往会随机地和任意一个ZooKeeper服务器保持连接，因此Leader服务器无法直接收到所有客户端的心跳检测，需要委托给Learner来保存这些客户端的心跳检测的客户端列表，同样以PING消息的形式反馈给Leader服务器，由Leader服务器来负责逐个对这些客户端进行会话激活。 |
| REVALIDATE，6 |
Learner→leader |
该消息用于Learner校验会话是否有效，同时也会激活会话。这通常发生在客户端重连的过程中，新的服务器需要向Leader发送REVALIDATE消息以确定该会话是否已经超时。 |
