分布式一致性协议2pc 3pc paxos zab 和zookeeper原理解析

从paxos到zookeeper 分布式一致性

本文从分布式系统到分布式事务的一致性的各种协议再到zk的是如何实现分布式事务的一致性的及其在分布式系统中的应用，最后附上zk的学习思维导图。

目录

从paxos到zookeeper 分布式一致性

1分布式架构演进

2.一致性协议

二阶段提交

阶段1：投票阶段（prepare阶段）

阶段二：事务提交阶段

三阶段提交

2.2 paxos算法

4. zk的zab协议 和paxos

API使用

Curator

Zk应用场景

大型分布式系统应用

zk技术内幕

zk的启动流程

zk的数据存储

逻辑结构znode

物理结构数据存储

Zab协议工作原理

恢复模式

广播模式

Zk运维

---

分布式架构演进

1. 大型主机，集中式到普通主机的分布式
2. 分布式事务
   1. 问题
      1. 通信异常
         1. 三态：成功，失败，超时
      2. 网络分区
         1. 脑裂：由于节点间的网络延时不断增加，会造成只有部分节点能正常通信，形成小集群，造成网络分区，有时网络分区会导致部分节点完成需要所有节点参与的事务
      3. 节点故障
   2. 从单机事务的acid到cap、base
      1. Acid
         1. A：只有成功或者失败
         2. C：数据是否正确状态
         3. I：幻读：两次事务，同样的读操作出现不一致，导致业务处理问题
            1.   
      2. Cap
         1. 分布式一致性（和单机事务一致性有区别）：副本之间的数据一致性，强一致性和弱一致性
         2. 可用性：正常的时间内返回正常的结果
         3. 分区容错性：任何分区错误，系统都能保证一致性和可用性，包括节点退出和加入
      3. Base
         1. Basic available 基本可用：时间损失，服务降级
         2. Soft state：允许存在中间状态的不一致
         3. Eventually consistency：最终状态一致     

一致性协议

 

每个节点不知道其他节点的事务提交情况，所以引入中间者进行协调。

二阶段提交

组织游泳活动需要买票和提交付款

阶段1：投票阶段（prepare阶段）

1. 协调者向事务参与者发起事务询问
2. 参与者在本地执行事务start，并执行事务，但不提交
3. 参与者返回事务start的结果

阶段二：事务提交阶段

协调节点根据参与者的反馈判断是否执行事务的提交，两种情况：

1.如果参与者阶段一都返回ok，则协调节点向参与节点发起commit

2.参与者commit本地事务，并返回ack

如果参与者阶段一返回的都是no，或者后节点超时

协调节点发起rollback请求，参与节点都rollback

优缺点：

1. 简单实现
2. 会发生阻塞
3. 提交阶段参与节点commit消息丢失

三阶段提交

基本和2pc差不多，准备阶段之前加入了询问阶段，询问参与节点是否可以执行事务，降低了事务准备节点的阻塞概率，但是没有解决commit丢失的情况。

 

paxos算法

参考：Paxos made simple

paxos是非常健壮的分布式一致性协议，也导致他非常的复杂难懂，待补充。

 

zk的zab协议 和paxos

zk的设计目标是分布式协调服务，采用的是zab协议叫原子广播，比paxos更简单，设计目标的假设条件也更宽松。

Zk提供分布式一致性服务包括：

1. 命名服务，域名服务
2. 负载均衡
3. Pubsub
4. 队列
5. 分布式锁
6. 配置管理
7. 服务发现注册

API使用

Curator

提供了很多实用功能的实现：

1. 节点监听
2. 选举master
3. 分布式锁
4. 分布式计数器，元子类
5. 分布式barrier
6. 队列
7. 分布式信号

Zk应用场景

分布式协调：核心都是基于znode的顺序一致性和通知机制，基本都是分布式锁的逻辑。

1. 配置服务
2. 动态dns
3. Uuid
4. 协调通知
5. 集群管理：实现高可用

大型分布式系统应用

1. Yarn
   1. 集群管理：实现主备切换，高可用
   2. 防止脑裂：fencing，通过acl判断是否是master，预防master假死后恢复的情况
2. Hbase
3. Kafka
   1. Broker注册
   2. Topic注册
   3. 生产和消费负载均衡
   4. Offset记录
4. Otter和cannal
5. Jstorm

这里有张zk的知识图谱：

zk技术内幕

架构图

zk的启动流程

zk的数据存储

逻辑结构znode

1. 节点版本号：和节点的顺序号不是一样的
   1.   
2. znode的ACL
   1.  权限模式：授权对象：权限
      1. 权限模式
         1. Ip
            1. 指定ip
         2. Digest
            1. 通过特定字段组合的hash值，如：name+passwd
      2. 授权对象id
         1.  
      3. 权限
         1. CDRWA，A：admin
   2. 可以自定义权限管理器
   3. 使用
      1. Create path data acl
      2. Setacl path acl

物理结构数据存储

1. 内存数据
2. 事务日志，datalogdir
   1. Zxid 结尾命名，固定大小分片
   2. 事务日志保存，事务相关数据和操作
3. 数据快照，datadir

Zab协议工作原理

zab的工作原理分两种情况：一种是服务启动或者故障重启恢复，一种是写事务提交这种也叫广播模式

1. 恢复模式

   1. 场景重启、故障、断网
   2. 主要作用是选leader
      1.  
      2. 选票的结构
         1. 
      3. 节点的类型
         1. leader：负责接收事务提交
         2. follower：负责投票和复制leader的提交
         3. observer：负责同步数据，没投票权
      4. 节点的状态
         1. looking
         2. following
         3. observing
         4. leading
      5. 选举流程
         1.  
      6.  解释：

         1、自增选举轮次。Zookeeper规定所有有效的投票都必须在同一轮次中，在开始新一轮投票时，会首先对logicalclock进行自增操作。

         2、初始化选票。在开始进行新一轮投票之前，每个服务器都会初始化自身的选票，并且在初始化阶段，每台服务器都会将自己推举为Leader。

         3、发送初始化选票。完成选票的初始化后，服务器就会发起第一次投票。Zookeeper会将刚刚初始化好的选票放入sendqueue中，由发送器WorkerSender负责发送出去。

         4、接收外部投票。每台服务器会不断地从recvqueue队列中获取外部选票。如果服务器发现无法获取到任何外部投票，那么就会立即确认自己是否和集群中其他服务器保持着有效的连接，如果没有连接，则马上建立连接，如果已经建立了连接，则再次发送自己当前的内部投票。

         5、判断选举轮次。在发送完初始化选票之后，接着开始处理外部投票。在处理外部投票时，会根据选举轮次来进行不同的处理。

                        外部投票的选举轮次大于内部投票。若服务器自身的选举轮次落后于该外部投票对应服务器的选举轮次，那么就会立即更新自己的选举轮次(logicalclock)，并且清空所有已经收到的投票，然后使用初始化的投票来进行PK以确定是否变更内部投票。最终再将内部投票发送出去。

                       外部投票的选举轮次小于内部投票。若服务器接收的外选票的选举轮次落后于自身的选举轮次，那么Zookeeper就会直接忽略该外部投票，不做任何处理，并返回步骤4。

                       外部投票的选举轮次等于内部投票。此时可以开始进行选票PK。

                             6、选票PK。在进行选票PK时，符合任意一个条件就需要变更投票。

                                      若外部投票中推举的Leader服务器的选举轮次大于内部投票，那么需要变更投票。

                                     若选举轮次一致，那么就对比两者的ZXID，若外部投票的ZXID大，那么需要变更投票。

                                               若两者的ZXID一致，那么就对比两者的SID，若外部投票的SID大，那么就需要变更投票。

                              7、变更投票。经过PK后，若确定了外部投票优于内部投票，那么就变更投票，即使用外部投票的选票信息来覆盖内部投票，变更完成后，再次将这个变更后的内部投票发送出去。

                              8、选票归档。无论是否变更了投票，都会将刚刚收到的那份外部投票放入选票集合recvset中进行归档。recvset用于记录当前服务器在本轮次的Leader选举中收到的所有外部投票（按照服务队的SID区别，如{(1, vote1), (2, vote2)...}）。

                              9、统计投票。完成选票归档后，就可以开始统计投票，统计投票是为了统计集群中是否已经有过半的服务器认可了当前的内部投票，如果确定已经有过半服务器认可了该投票，则终止投票。否则返回步骤4。

                              10、更新服务器状态。若已经确定可以终止投票，那么就开始更新服务器状态，服务器首选判断当前被过半服务器认可的投票所对应的Leader服务器是否是自己，若是自己，则将自己的服务器状态更新为LEADING，若不是，则根据具体情况来确定自己是FOLLOWING或是OBSERVING。

                               以上10个步骤就是FastLeaderElection的核心，其中步骤4-9会经过几轮循环，直到有Leader选举产生。参考：https://www.cnblogs.com/veblen/p/10992103.html

1. 广播模式

   1. 场景：写请求
   2. 写的事务请求都是转发到leader节点进行的
   3. 如何保证顺序一致性
      1. 每次广播生成全局唯一的zxid
      2. 执行过半二阶段提交
         1. Foller有个fifo队列，每次proposal都有将先写事务日志，leader也写事务日志，leader发起commit后提交事务，follower也提交，如果leader收到过半节点的提交确认则认为事务提交成功。
      3. 所有提交有唯一的Zxid，leader会Currenthashmap保存所有待提交的zxid，leader提交前会判断是否有比当前收到的ack对应的zxid小的zxid未提交，如果有则当前的zxid即使过半了也不能提交。
2. 和paxos的区别
   1. Zk是分布式主从协议
   2. Pxs是分布式一致性协议：https://zhuanlan.zhihu.com/p/31780743

Zk运维

zk的运维也是很重要的一块，如何进行容灾和高可用还能达到一致性和分区容错性，包括：

1. Jmx
2. 命令
3. 参数配置
4. 集群，节点数奇数
5. 多机房部署，每个机房的节点数，防止脑裂
6.       3机房
7.       2机房
8. 集群扩容缩容
   1. 需要重启，一台台重启

本文地址：https://blog.csdn.net/Houson_c/article/details/111996638