zookeeper的2PC、3PC、ZAB协议的深入讲解

zookeeper解决分布的问题

主要解决分布式环境下的服务协调问题。
1、防止单点故障
搭集群，满足高性能分担客户端的请求流量，高可用某一个宕机不影响数据和提供服务的可能性。
2、数据一致性-2PC3PC
3、leader选举-ZAB
leaderg挂了如何恢复数据？

2PC：两个阶段。

阶段一：提交事务请求
1.事务询问
协调者向参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待参与者的响应。
2.执行事务
各个参与者节点执行事务操作，并将Undo和Redo信息记录到事务日志中，尽量把提交过程所消耗的时间和准备都提前完成确保后面100%成功提交事务。
3.各个参与者反馈给协调者事务询问的响应
如果参与者成功执行了事务操作，反馈给协调者yes的响应表示事务可以执行。否则不可以执行。类似于投票过程，接下来参与者投票表是否需要继续执行事务提交操作。
阶段二：执行事务提交
协调者根据各参与者的反馈情况决定是否可以进行事务提交操作，正常情况下包含两种可能：执行事务、中断事务。过半执行事务

在zookeeper集群中：

在 zookeeper 中，客户端会随机连接到 zookeeper 集群中 的一个节点，如果是读请求，就直接从当前节点中读取数 据，如果是写请求，那么请求会被转发给 leader 提交事务， 然后 leader 会广播事务，只要有超过半数节点写入成功， 那么写请求就会被提交(类 2PC 事务)

所有事务请求必须由一个全局唯一的服务器来协调处理， 这个服务器就是 Leader 服务器，其他的服务器就是follower。leader 服务器把客户端的失去请求转化成一个事 务 Proposal(提议)，并把这个 Proposal 分发给集群中的所有 Follower 服务器。之后 Leader 服务器需要等待所有Follower 服务器的反馈，一旦超过半数的 Follower 服务器 进行了正确的反馈，那么 Leader 就会再次向所有的Follower 服务器发送 Commit 消息，要求各个 follower 节点对前面的一个 Proposal 进行提交;

集群角色

1. Leader（Leader服务器是整个zookeeper集群的核心，主要的的工作有两项。）
2. 事务请求的唯一调度和处理者，保证集群事务处理的顺序性
3. 集群内部各服务器的调度者
4. Follower
5. 处理客户端非事物请求、转发事物请求给leader服务器2. 参与事物请求 Proposal 的投票(需要半数以上服务器 通过才能通知 leader commit 数据; Leader 发起的提案， 要求 Follower 投票)
6. 参与 Leader 选举的投票
7. Observer
8. 观察者的角色，观察 zookeeper 集群中的最新状态变化并将这些状态变化 同步到 observer 服务器上
9. Observer 的工作原理与follower 角色基本一致，而它和 follower 角色唯一的不同 在于 observer 不参与任何形式的投票
10. observer服务器只提供非事物请求服务，通常在于不影响集群事物 处理能力的前提下提升集群非事物处理的能力

集群组成

1. zookeeper 是由 2n+1 台 server 组成，每个 server 都 知道彼此的存在。
2. 如果一台由 6 台服务构成的集群，同样只能挂掉 2 台机器。因此，5 台和 6 台在容灾能力上并没有明显优势，反而增加了网络通信负担。
3. 系统启动时，集群中的 server 会选举出一台server 为 Leader，其它的就作为 follower
4. 以上说明observer越多反而减少了网络通信的负担。
   

ZAB协议

选举leader

初始化都为looking