二阶段提交协议(Two-Phase Commit)

• 背景
  在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败

• 假设
  • 分布式系统中，存在一个节点作为协调者(Coordinator)，其他节点作为参与者(Participants)，且节点之间可以进行网络通信
  • 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失
  • 所有节点不会永久性损坏，即使损坏后仍然可以恢复
• 概括
  • 参与者 将操作成败通知 协调者，再由 协调者 根据 所有参与者 的反馈情报决定 各参与者 是否要 提交操作 还是 中止操作
• 阶段一(投票阶段)
  • 事务(是否可以提交事务)询问
    • 协调者 向所有的 参与者 发送事务内容，询问是否可以执行 事务提交 操作，并开始等待各 参与者 的响应
  • 执行事务
    • 各 参与者节点 执行事务操作，并将Undo和Redo信息记入事务日志中
  • 各 参与者 向 协调者 反馈事务询问的响应
    • 如果参与者成功执行了事务操作，则反馈YES响应，否则返回NO响应
• 阶段二(完成阶段)
  • 协调者 从所有 参与者 获得的反馈都是YES响应
    • 发送提交请求
      • 协调者 向所有 参与者节点 发出COMMIT请求
    • 事务提交
      • 参与者接收到COMMIT请求后，会正式执行事务提交操作，并在完成提交之后 释放 在整个事务执行期间占用的事务资源
    • 反馈事务提交结果
      • 参与者 在完成事务提交之后，向 协调者 发送ACK消息
    • 完成事务
      • 协调者 接收到所有 参与者 反馈的ACK消息后，完成事务
  • 任何一个 参与者 向 协调者 反馈了NO响应
    • 发送回滚请求
      • 协调者 向所有 参与者节点 发送 ROLLBACK 请求
    • 事务回滚
      • 参与者 接收到ROLLBACK请求后，会利用其在阶段一中记录的UNDO信息来执行事务回滚操作，并在完成回滚之后 释放 在整个事务执行期间占用的资源
    • 反馈事务回滚结果
      • 参与者 在完成事务回滚之后，向 协调者 发送ACK消息
    • 中断事务
      • 协调者 接收到 所有参与者 反馈的ACK消息后，完成事务中断
• 缺点
  • 同步阻塞
    • 所有(参与者)参与该事务操作的逻辑都处于阻塞状态
    • 其它访问该事务操作锁定的资源的操作也会被阻塞
  • 单点问题
    • 协调者出现问题则整个二阶段提交流程将无法运行
    • 如果协调者在阶段二中出现问题，则其他参与者将会一直处于锁定事务资源的状态，而无法继续完成事务操作
  • 数据不一致
    • 可能只有部分参与者收到了COMMIT请求，并执行了提交；其他结点没有收到COMMIT请求从而无法提交
  • 太过保守
    • 当参与者出现故障，导致协调者始终无法获取所有参与者的响应信息时，协调者只能依靠自身的超时机制判断是否需要中断事务

ZAB协议(ZooKeeper Atomic Broadcast)

• 作用
  • 保证分布式事务的最终一致性
• 要解决的问题
  • 正确、高效地处理客户端大量的并发请求
  • 分布式环境中，要保证一个全局的变更序列被顺序应用
  • 容错处理(这一点是基于解决第1点问题使用的 主备模式 而提出)
• 核心概念
  • 协议定义
    • 并不像Paxos算法那样的通用的分布式一致性算法
    • 是一种特别为ZooKeeper设计的崩溃可恢复的原子消息广播算法
  • Leader服务器
    • 所有事务请求必须由一个全局唯一的服务器来协调处理
  • Follower服务器
    • 余下的其他服务器
  • 基本流程
    • Leader负责将一个客户端事务请求转换成一个事务Proposal(提议)，并将该Proposal分发给集群中所有Follower
    • Leader等待超过半数的Follower进行正确反馈
    • Leader向所有Follower分发Commit消息，要求将前一个Proposal进行提交
  • 举例
    • Zookeeper 客户端会随机的链接到 zookeeper 集群中的一个节点
    • 如果是读请求，就直接从当前节点中读取数据
    • 如果是写请求，那么节点就会向 Leader 提交事务，Leader 接收到事务提交，会广播该事务，只要超过半数节点写入成功，该事务就会被提交
• 基本模式
  • 崩溃恢复
    • Leader选举
      • 选举出一个Leader，同时Leader会维护一个Follower列表，客户端可以和这些 Follower进行通信
      • 协议并没有规定选举算法
      • 实现中使用的如：Fast Leader Election
    • 数据同步
      • Leader要负责将本身的数据与Follower完成同步，做到多副本存储。这样也是提现了CAP中的高可用和分区容错
      • Follower将队列中未处理完的请求消费完成后，写入本地事务日志中
  • 消息广播
    - Leader可以接受客户端新的事务Proposal，将新的Proposal广播给所有的Follower
• 关键概念及理解
  • ZAB协议的主备模型(具体的说就是核心概念中的介绍)
    • 能够很好地处理客户端大量的并发请求
  • 消息广播是基于具有FIFO特性的TCP协议来进行网络通信的
    • 能够很容易的保证消息处理过程中消息收、发的顺序性
  • 换一种说法：Leader与每一个Follower之间都维护了一个单独的FIFO消息队列进行收发消息
    • 消息队列可以做到异步解耦：Leader和Follower之间只需要往队列中发消息即可
  • ZAB协议中Leader等待Follower的ACK反馈消息：只要半数以上的Follower成功反馈即可，不需要收到全部Follower反馈
    • 相比二阶段提交协议，做了简化，提高了性能
• 崩溃恢复需要保证的两点原则
  • ZAB协议需要确保那些已经在Leader上提交的事务Propocal，最终被所有服务器都提交
  • ZAB协议需要确保在丢弃只在Leader上提出的事务Proposal (而没有被提交)

参考

https://www.jianshu.com/p/2bceacd60b8a
FastLeaderElection选主算法流程详解
Zookeeper架构及FastLeaderElection机制

原文：https://www.cnblogs.com/wangzhiyi/p/11298686.html