zookeeper基础（同步模式与广播模式）

初始化同步

上一篇说过，恢复模式具有两个阶段：Leader选举和初始化同步。当完成Leader选举后，此时的Leader 还是一个准Leader，其要经过初始化同步后才能变成 真正的Leader。

具体过程如下：
1） 为了保证Leader向Learner发送提案的有序，Leader会为每一个Learner 服务器准备一个队列
2） Leader 将那些没有被各个Leader同步的事务封装为Proposal
3） Leader 将那些Proposal逐条发给各个Learner，并在每个Proposal后紧跟一个Commit消息，表示该事务已经被提交，Learner可以直接接收并执行
4） Learner接收来自于Leader 的 Proposal，并将其更新到本地
5） 当Learner 更新成功后，会向准Leader 发送ACK信息
6） Leader 服务器在收到来自Learner的ACK后就会将该Learner加入到真正可用的Follower列表或Observer列表。没有反馈ACK，或反馈了但Leader没有收到的Learner，Leader不会将其加入到相应列表。

消息广播算法

当集群中的Learner完成了初始化状态同步，那么整个zk集群就进入到了正常工作模式了。
如果集群中的Learner 节点收到客户端的事务请求，那么这些Learner会将请求转发给Leader服务器。然后再执行如下过程：

1. Leader接收到事务请求后，为事务赋予一个全局唯一的64位自增id，即zxid，通过zxid的大小比较即可实现事务的有序性管理，然后将事务封装成一个Proposal。
2. Leader 根据Follower 列表获取到所有的Follower，然后将Proposal通过这些Follower的队列将提案发送给各个Follower。
3. 当Follower 接收到提案后，会先将提案的zxid与本地记录的事务日志中的最大zxid进行比较。若当前提案的zxid大于最大zxid，则将当前提案记录到本地事务日志中，并向Leader 返回一个ACK。
4. 当Leader接收到过半的ACKs后，Leader 就会向所有Follower 的队列发送Commit 消息，向所有Observer的队列发送Proposal。
5. 当Follower接收到Commit消息后，就会将事务正式更新到本地。当Observer 收到Proposal 后，会直接将事务更新到本地。
6. 无论是Follower 还是 Observer ，在同步完成后都需要向Leader 发送成功ACK。

Observer的数量问题

**Observer 数量并不是越多越好，一般与Follower数量相同。**因为Observer数量的增多随不会增加事务操作压力，但需要从Leader同步数据，**Observer同步数据的时间是小于等于Follower同步数据时间的。**当Follower同步数据完成，Leader的Observer列表中的Observer主机将结束同步，那些完成同步的Observer将进入到另一个对外提供服务的列表。那么，那些没有同步了数据无法提供服务的Observer主机就形成了资源的浪费。
所以，对于事务操作发生频繁的系统，不建议使用过多的Observer。

Leader中保存的Observer列表其实有两个：
all： 包含所有的Observer。
service：已经完成了从Leader 同步数据的任务。service <= all.其是动态的。

Leader中保存的Follower列表其实也有两个：
all：要求其中必须有过半的Follower向Leader 反馈ACK
service：已经完成了从Leader 同步数据的任务。service <= all.其是动态的。