一、zookeeper设计猜想

问题的引出(缺少分布式协调机制)

利用zookeeper特性，三个服务都在zookeeper上注册节点，最小的节点具有优先权，让它执行其他两个不让他执行

假如zookeeper成我们项目中的核心，那么zookeeper势必会带来高可用高性能的一些挑战

设计猜想

1.防止单点故障

集群方案(leader，follower)，还能分担请求

2.每个节点数据一致的（必须要有leader）

leader ，master

3.leader挂了怎么办？数据如何恢复

选举机制？数据恢复？

4.如何保证数据一致性？（分布式事务）

2PC协议（二阶提交）

结论

1.zab来实现选举

2.为什么要做集群

3.2pc做数据一致性

二、zookeeper集群角色

改进版2pc不需要全部角色同意

所以集群中必须存在2n+1各节点保证投票正常进行

三、深入分析zab协议

支持崩溃恢复的原子广播协议，主要实现数据一致性

崩溃恢复

1.当leader失去国办的follower节点的联系

2.leader挂掉

集群就会进入崩溃恢复的阶段

对于数据恢复来说

1.已经处理的数据不能丢失

当leader收到合法数量follower的ack以后，就会向哥哥follower广播消息（commit命令），同时自己也会commit这条事务的消息。如果follower节点收到commit命令之前leader挂了，会导致部分节点收到commit消息，部分节点没有收到。那么zab协议需要保证已经处理的消息不能丢失

2.被丢弃的消息不能再次出现

当leader收到事务请求，并且还未发起投票请求之前，leader挂了。

zab的设计思想

1.zxid是最大的，保证消息是最新的（64位数据）

2.epoch的概念

每产生一个新的leader新的leader的epoch会在原来的基础上加1

现在我们把leader停掉，会选出新的leader查看epoch会再上一个leader基础上加1

事务日志的查看

消息广播

改进版本的2pc

leader收到事务请求后，会给这个消息赋予一个zxid（64位自增id）

leader将带有zxid的消息作为一个propose（提案）分发给集群中的每一个follower节点

follower节点把propose这个事务写入磁盘

写入成功后返回一个ack给leader

当leader受到合法数量（过半数）的ack后发起commit请求

广播过程投票不需要observer的参与

leader选举

fast leader

zxid最大会设置成leader（事务id）事务id最大表示数据最新

epoch（每一轮投票都会递增）

myid（服务器id，sid）

myid越大，在leader选举中权重最大

选举状态（looking）

leading

following

observing

启动时初始化

每个节点会将myid zxid epoch发布给集群中的每一个节点，每个节点收到信息后会进行投票比较这些数据

1.检查zxid如果zxid比较大就会投给这个节点

2.如果zxid一样（刚启动时）就会比较myid，myid比较大的会作为leader

3.更新epoch

两种情况下回选取leader

第一种启动时

第二种leader崩溃时

zookeeper核心原理