zookeeper的zab协议原理

zookeeper的集群特点

 顺序一致性
客户端的更新顺序与它们被发送的顺序相一致。
 原子性
更新操作要么成功要么失败，没有第三种结果。
 单一视图
无论客户端连接到哪一个服务器，客户端将看到相同的 ZooKeeper 视图。
 可靠性
一旦一个更新操作被应用，那么在客户端再次更新它之前，它的值将不会改变。
 实时性
连接上一个服务端数据修改，所以其他的服务端都会实时的跟新，不算完全的实时，有一点延时的
 角色轮换避免单点故障
当leader出现问题的时候，会选举从follower中选举一个新的leader

zookeeper的角色

 Leader 集群工作机制中的核心
事务请求的唯一调度和处理者，保证集群事务处理的顺序性
集群内部个服务器的调度者(管理follower,数据同步)
 Follower 集群工作机制中的跟随者
处理非事务请求，转发事务请求给Leader
参与事务请求proposal投票
参与leader选举投票
 Observer 观察者
3.30以上版本提供，和follower功能相同，但不参与任何形式投票
处理非事务请求，转发事务请求给Leader
提高集群非事务处理能力

zookeeper的zab解析

zookeeper就是根据zab协议建立了主备模型完成集群的数据同步（保证数据的一致性），前面介绍了集群的各种角色，这说所说的主备架构模型指的是，在zookeeper集群中，只有一台leader（主节点）负责处理外部客户端的事务请求（写操作），leader节点负责将客户端的写操作数据同步到所有的follower节点中。

zab协议核心是在整个zookeeper集群中只有一个节点既leader将所有客户端的写操作转化为事务（提议proposal）.leader节点再数据写完之后，将向所有的follower节点发送数据广播请求（数据复制），等所有的follower节点的反馈，在zab协议中，只要超过半数follower节点反馈ok,leader节点会向所有follower服务器发送commit消息，既将leader节点上的数据同步到follower节点之上。

发现，整个流程其实和paxos协议其实大同小异。说zab是paxos的一种实现方式其实并不过分。
Zab再细看可以分成两部分。第一的消息广播模式，第二是崩溃恢复模式。

消息广播模式

zookeeper中消息广播的具体步骤如下：

1. 客户端发起一个写操作请求
2. Leader服务器将客户端的request请求转化为事物proposql提案，同时为每个proposal分配一个全局唯一的ID，即ZXID。
3. leader服务器与每个follower之间都有一个队列，leader将消息发送到该队列
4. follower机器从队列中取出消息处理完(写入本地事物日志中)毕后，向leader服务器发送ACK确认。
5. leader服务器收到半数以上的follower的ACK后，即认为可以发送commit
6. leader向所有的follower服务器发送commit消息。

zookeeper采用ZAB协议的核心就是只要有一台服务器提交了proposal，就要确保所有的服务器最终都能正确提交proposal。这也是CAP/BASE最终实现一致性的一个体现。

崩溃恢复模式

ZAB协议崩溃恢复要求满足如下2个要求：
确保已经被leader提交的proposal必须最终被所有的follower服务器提交。
确保丢弃已经被leader出的但是没有被提交的proposal。

新选举出来的leader不能包含未提交的proposal，即新选举的leader必须都是已经提交了的proposal的follower服务器节点。同时，新选举的leader节点中含有最高的ZXID。这样做的好处就是可以避免了leader服务器检查proposal的提交和丢弃工作。

 每个Server会发出一个投票,第一次都是投自己。投票信息：（myid，ZXID）
 收集来自各个服务器的投票
 处理投票并重新投票，处理逻辑：优先比较ZXID,然后比较myid
 统计投票，只要超过半数的机器接收到同样的投票信息，就可以确定leader
 改变服务器状态

问题：为什么优先选大的zxid
答案:
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务
当leader挂了的时候，比较其他server哪个server上的数据比较新的依据，当leader接受写操作，只同步了一个server,这个时候挂了，那么这个最新的server就是下一个leader