Two-phase Commit protocol

发表于

2PC提交协议

概述

在分布式系统中，每个节点虽然可以知道自己的操作是否成功，但当一个事物跨越多个节点时，为了保证事务的ACID特性，系统需要引入一个协调者组件来管控所有节点的操作；

2 Phase Commit（简称2PC）协议是在分布式事务中，用于在多个节点达成一致性的协议。

协议内容

  • 角色

    • 一个协调者(coordinator，事务管理器)和多个参与者(participant，资源管理器)

  • 操作流程

    • Prepare阶段：
      • 协调者会向所有参与者发送prepare命令，然后开始等待参与者节点的响应；
      • 参与者会询问发起为止的所有实务操作，并将Undo和Redo信息持久化日志，此时会将事务在本地提交；
      • 向协调者应答commit同意或abort失败，协调者收到之后会将信息反馈到客户端；
    • commit阶段：在这个阶段，会根据不同的应答执行操作
      • 成功：当所有参与者节点都应答"同意"；
        • 协调者向所有参与者节点发出"正式commit"的请求；
        • 参与者节点本地完成操作，并释放在整个事务期间占用的资源；
        • 参与者节点向协调者节点应答“完成”；
        • 协调者收到完成之后，完成事务；
      • 失败：存在参与节点在第一阶段响应“终止”，或者协调者等待超时
        • 协调者向所有参与者节点发出“回滚操作”的请求；
        • 参与者节点本地利用之前写入的Undo日志执行回滚，并释放相关资源；
        • 参与者向协调者反馈“回滚完成”；
        • 协调者收到所有信息之后，取消事务；

    两阶段完成之后，无论结果如何，协调者都必须要在此结束当前事务；

流程如下：

Coordinator

img

Participant

img

2PC的缺点

尽管2PC看起来能提供原子性的事务，但其也有局限：

  1. 同步阻塞：这是2PC最大的缺点，在执行过程中，节点都处于阻塞状态，即节点之间都在等待对方的相应消息。一旦协调者宕机，整个事务进程将会被阻塞；而参与者崩溃，则可能会导致协调者无法收到消息，执行保守的回滚政策；另外就是，一旦协调者发出了commit消息之后宕机，而唯一接收到这消息的参与同时崩溃，即便重新选出了协调者，那么这条事务的状态也是不确定的；
  2. 延迟：在prepare和commit两阶段，至少会产生两次RPC延迟，和三次持久化数据的延迟——prepare写日志+协调者状态持久化+commit写日志

总结

相比2PC，3PC能解决一些单点故障和阻塞的问题，但都无法彻底解决分布式的一致性问题，只有Paxos算法才是完整的一致性算法

there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos. ——————Mike Burrows

Reference

  1. https://en.wikipedia.org/wiki/Two-phase_commit_protocol
  2. https://zhuanlan.zhihu.com/p/22594180
  3. https://www.hollischuang.com/archives/681