zookeeper协调原理

朴灿烈づ我的快乐病毒、 2021-12-03 05:43 376阅读 0赞

### zookeeper协调原理 ###

*   *  CAP原理
     *  事务请求
     *  传统2pc
     *  ZAB协议-事务广播
     *  ZAB协议-崩溃恢复

欢迎查看Eetal的第二十四篇博客–zookeeper协调原理

## CAP原理 ##

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。  
一致性表示分布式系统中各个节点数据的一致性  
可用性代表数据访问的高性能  
分区容错性指的是因为同步的时间问题，数据不一致导致出现了多个不同数据版本的分区现象，但系统仍能继续正常运行（容错）  
很显然，三者最多只能取其二  
分区容错性与一致性共存（同步需要阻塞）必会与可用性冲突  
分区容错性与可用性共存（数据不同步）必会与一致性共存冲突  
可用性与一致性共存必会与分区容错性冲突（实际上这个是不实际的需求，因为分布式环境下因为网络通信的延迟分区容错性是必要的）  
综上，大部分分布式架构都是实现数据的最终一致性而非实现强一致性（因为分区容错性的必然存在）  
zookeeper的zap协议就是对2pc进一步提高分区容错性与可用性而降低强一致性的一种协议，同时其保证最终一致性，所以在分布式环境下仍是可用的

## 事务请求 ##

所有事务请求（增删改）都会转发到leader由leader处理  
zookeeper内部是依赖一个改进版的2pc——ZAB协议

## 传统2pc ##

传统2pc分为两个阶段preCommit和commit阶段  
preCommit阶段由leader向所有节点发送事务请求，各自执行后向leader返回执行成功或者失败，但不进行commit操作（锁资源，将undo和redo信息写到事务日志）  
commit阶段可由以下几种情况触发:  
1.超时没有收到所有节点反馈  
2.某个节点反馈失败  
3.全部节点返回成功  
到了commit阶段，1和2两种情况都会触发rollback，leader向参与本次事务的所有节点发送rollback命令，每个节点读取undo，执行事务回滚  
第3种情况，leader向所有参与本次事务的节点发送commit命令，每个节点读取redo，执行事务提交  
commit阶段以后，每个节点才会释放资源，切这个过程是同步的，且单点影响较大，单个节点故障会导致集群事务失败

## ZAB协议-事务广播 ##

ZAB协议是一个中心化的分布式协调协议（非中心化的如redis的gossip——原理和网络协议的泛洪法类似）  
ZAB协议对于事务请求，采取过半选举原则，对于分区容错性进行宽容但避免了单点问题，因为最终会进行数据同步，所以还是能保证分布式环境下数据的最终一致性  
preCommit阶段，zookeeper的leader节点收到follower发送的事务请求，执行该事务不提交并封装为PROPOSAL消息（包含redo、undo等），向所有follower节点下发该PROPOSAL消息  
follower节点收到PROPOSAL消息后，将对应的数据信息写到磁盘日志文件返回ack，如果写入失败则抛弃leader，重新加入集群（会等到事务结束才能成功）进入数据同步阶段  
commit阶段，当超时时间到来前，leader节点收到参与投票的节点（follower节点+leader）超过半数以上的ack时，认为本次事务成功，向所有follower节点广播commit消息（只有zxid），并向observer发送INFORM消息（包含PROPOSAL消息），要求每个节点将PROPOSAL消息执行事务提交（写入内存）  
如果超时没有收到半数以上的commit，认为本次事务失败，向所有follower节点广播rollback消息，因为提交事务了，执行了该操作的所有zookeeper服务器的zxid会+1  
接下来，集群所有节点在与leader通信时，发现zxid比leader小的（重新加入集群那部分），leader就会发送命令进行数据同步

## ZAB协议-崩溃恢复 ##

zookeeper集群下，非leader节点出现崩溃只要不影响选举，因为重新启动以后连接集群都要与leader通信，比较zxid进行数据同步，较好解决  
而leader节点如果崩溃，一般要面临重新选举，选举也是采用半数通过原则（每次选举都会将当前结点能收到消息的，收到最多投票的节点作为下一次选举对象，如果选举对象没有获得半数以上选票会重复这个过程）  
leader选举后，就面临数据同步问题  
集群内的有两种  
1.旧leader收到的事务请求但还没有发出的  
2.旧leader发出commit操作但是还没有收到全部反馈的  
对于第一种情况，zookeeper采取的策略是直接丢弃，对执行了该事务未提交的机器进行rollback  
实现原理基于zxid的设计，zxid是64位，高32位为epoch，低32位为PROPOSAL事务计数器  
epoch为leader编号，每换一次leader会+1  
对于第二种情况，zookeeper采取的策略是保证全部提交，这时如果有follower中保存有盖zxid的PROPOSAL事务而未提交，leader会发送commit命令

更多文章，请搜索公众号歪歪梯Club  
![更多资料，请搜索公众号编程宝可梦][20200521183346518.jpg]

[20200521183346518.jpg]: /images/20211203/72a760d0c7e2499b8b0c7553dad1eaa5.png