文章目录
概述
在集群环境下客户端可能会请求不同的zookeeper完成相应的节点操作，那么集群之间zookeeper是如何实现数据同步的呢？本篇文章就会基于四种情况进行分析。
先行概念
leader工作流程涉及的代码角色
PrepRequestProcessor
负责接受客户端的请求，进行相应预处理标记操作操作
ProposalRequestProcessor
接收PrepRequestProcessor 发送过来的请求内容，具体如下流程图所示，总的来说就是当出现写操作时就得通知sync对象进行操作记录：
Commit
leader工作流程中有个事务管理对象，具体工作流程图如下所示，简明来说就是当ProposalRequestProcessor 传来的请求是写请求就进行日志记录一下，当有需要提交的事务时就进行提交，否则就继续往复之前的操作
Sync
简单来说就是出现写请求时候需要对操作进行日志记录一下
Ack
当Sync完成操作归档后，就会让ack通知leader本次归档完成。
Final
最终执行操作的工作角色
通知follower信号
REQUEST
PROPOSAL
ACK
COMMIT
follower工作流程设计的代码角色
follower工作流程大体上不变，仅仅是将PrepRequestProcessor 改为FollowerRequestProcessor 。以及ack变为SendAck
FollowerRequestProcessor
SendAckRequestProcessor
SendAckRequestProcessor 的逻辑是当sync完成操作信息归档后，通知leader当前操作记录归档完成
实际工作流程
客户端基于leader的读请求流程
具体工作流程如下流程图所示，很明显，基于leader的读请求很简单，只要预处理preRequestProcessor完成操作标记之后一路交给final完成数据查询返回即可。
客户端基于leader的写请求
写请求就比较复杂了，如下图所示，当leader收到客户端的写请求，首先prep会进行写操作标记，然后交给proposal，proposal会通知follower当前有一个写请求的信息(需要了解是，这条信息中会注明事务编号，为了严格保证提交事务的顺序，每一次的写事务分配一个唯一的递增数字，从 0 开始)，双方都进行sync操作记录后，都会发送一个ack给leader，当半数以上的zookeeper收到ack确认后，都会通知各自的commit提交事务，让final完成事务提交。
客户端基于follower的读请求
可以看出follower的读请求与leader无异，只是预处理人是followerRequestProcessor而已
客户端基于follower的写请求
如下图流程图所示，同步流程可以简述为follower收到写请求后会交给leader进行处理，leader通知所有follower写操作请求后，当半数以上zookeeper完成写操作日志创建并发送ack确认后，所有commit都会提交事务，由final完成写操作。
