一、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崩溃时
网友评论