由于BASE理论需要在一致性和可用性方面做出权衡，因此涌现了很多关于一致性的算法和协议。其中比较著名的有二阶提交协议（2 Phase Commitment Protocol），三阶提交协议（3 Phase Commitment Protocol）和Paxos算法。

文章目录

前言
单机事务和分布式事务
一致性协议的一些思路
2PC二阶段提交协议基本过程
- 节点角色
- 两个阶段
- - 准备阶段
  - 提交阶段
2PC协议的异常分析
2PC协议的优缺点
本文小结

前言

前面一篇文章和大家一起学习了下分布式系统一致性问题的一些理论，其中重点是理解PACELC理论、BASE理论等问题，让我们对于分布式一致性的重点是什么有一些认识。在了解分布式一致性的理论和概念之后，后续将和大家一起讨论分布式一致性协议，其中包括：2PC、3PC、Paoxs协议、Raft协议。篇幅有限，本文重点展开2PC协议，后续文章继续深入。

单机事务和分布式事务

在聊2PC和3PC之前，我们有必要先了解下单机事务和分布式事务。事务是一组原子操作，要么全成功要么全失败 All or Nothing，否则就会出现数据混乱，这种需求在金融和电商领域很普遍。试想你去天猫买了台mac，订单服务、扣款服务、库存服务出现任何一个环节的失败都会带来问题，所以就需要事务来做保证，一荣俱荣一损俱损。

单机事务具备ACID特性，大家都比较喜欢，但是单机的能力毕竟有限，我们常常必须在分布式场景下同样完成这一组原子操作，也就是分布式事务。

由于分布式系统中各个子服务是部署在不同的物理节点上，不同交换机、不同机房、不同城市，这样以来，要想像单机系统一样完成这一组原子操作就没那么容易了，因此就出现了很多分布式一致性协议和算法，来解决分布式事务问题保证数据一致性。

分布式系统的各个节点只能依靠网络来进行数据通信，但是网络往往并不完全可靠，同时节点物理故障也时常发生，在这样一个复杂的环境中去保证数据一致性确实不太容易。

一致性协议的一些思路

突兀地去学习一个新的协议或者算法往往比较生硬，不如思考一下生活现象，大部分的计算机领域的算法和思想在实际生活中都有映像，又或者说算法来源于生活。

举个栗子：在规模盛大的阅兵仪式中会有陆海空多兵种多方队，为了让命令和节奏准确地下达，我们需要乐曲、指挥、领队、排头、队员等多种角色。整个活动需要在不同角色的相互作用之下，才能让一个数量庞大的个体组成一个整体来完成一个目标。

再举个栗子：2018年5月在西安举行了一场盛大的无人机编组飞行灯光秀，共计1374架无人机组成一个庞大的编组来完成灯光表演，但是还是出现了问题，并未上演完美图案：

分布式系统也是如此，为了让很多参与的机器节点节奏步调一致，我们就需要不同的角色各司其职，共同完成一项任务，但是仍然困难重重，因为会有网络故障和节点物理故障等问题。

2PC二阶段提交协议基本过程

要理解2PC协议重点在于节点角色分工和两个阶段所执行的动作以及不同情况下的处理逻辑。

两阶段提交又称2PC,2PC是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（partcipant）。

2PC协议总体概览

节点角色

二阶段提交协议将节点分为：协调者和参与者，对于者两种角色，当然你也可以理解为Leader和大头兵。

协调者Leader，负责向参与者发送指令，收集参与者反馈，做出提交或者回滚决策
参与者大头兵，接收协调者的指令执行事务操作，向协调者反馈操作结果，并继续执行协调者发送的最终指令

两个阶段

2PC协议分为：准备阶段和提交阶段。

准备阶段

协调者向所有参与者节点发送询问并执行事务的命令，参与者节点收到命令后根据自己的状态执行或者不执行事务，并将动作记录下来，最后将对命令的处理结果反馈给协调者。

准备阶段的三个环节

1询问环节：协调者向参与者询问，是否准备好可以执行事务，之后协调者开始等待各参与者的响应，这个环节协调者处于阻塞等待状态。

2处理环节：参与者收到协调者的询问后根据自身情况来决定是否执行事务操作，如果参与者执行事务成功，将Undo和Redo信息记入事务日志，但不提交事务；否则直接返回失败。

3响应环节：当参与者成功执行了事务操作，就反馈yes给协调者，表示事务在本地执行；当参与者没有成功执行事务，就反馈no给协调者，表示事务不可以执行提交，这部分反馈对于协调者决策下个阶段起到非常重要的作用。

提交阶段

协调者根据准备阶段收到的参与者反馈来决定最终提交事务或者中断回滚事务，具体来说，当协调者在准备阶段结束时收到的响应反馈有一个no，那么就中断事务，如果收到的反馈全部是yes就提交事务。

情况一: 提交事务

如果在准备阶段结束时，协调者收到了来自所有参与者的yes反馈，接下来协调者就会向所有参与者发送提交事务指令，具体的过程如下：

步骤1. 协调者向所有参与者发送事务提交消息Commit命令

步骤2. 参与者在收到来自协调者的Commit命令之后，执行事务提交动作，并释放事务期间所有持有的锁和资源，这一步很重要

步骤3. 所有参与者在执行本地事务且释放资源完成后，向协调者发送事务提交确认消息ACK

步骤4. 协调者在收到所有参与者的ACK消息后确认完成本次事务

情况二: 回滚事务

如果在准备阶段结束时，协调者没有收到来自所有参与者的yes反馈，接下来协调者就会向所有参与者发送回滚事务指令，具体的过程如下：

步骤1. 协调者向所有参与者发送事务回滚消息Rollback

步骤2. 参与者收到Rollback回滚指令后，根据本地的回滚日志来撤销阶段一执行的事务，并释放事务期间所有持有的锁和资源

步骤3. 所有参与者在完成指令后向协调者回复反馈ACK

步骤4. 协调者在收到所有参与者的ACK确认消息后撤销该事务

通过上面的描述我们知道了，2PC协议通过将节点分为不同的角色，进行两个阶段的处理来执行分布式事务，但是难免要去想2PC协议可以真正解决分布式数据一致问题吗？

2PC协议的异常分析

前面的两个阶段涉及了多次协调者和参与者的网络通信交互，但是我们都知道网络是不可靠的，节点也能出现故障，因此必须要考虑异常情况下2PC协议是否仍然可以正常工作。

故障可以分为很多种：可恢复机器故障和不可恢复机器故障、网络正常抖动故障、网络分区故障等多种情况。

2PC整个过程交互也很多，不同阶段发生不同故障造成的结果也是不一样的，显然这是个m*n的组合问题，不同的异常情况会产生不同的结果要完全列出来并分析绝非易事，我们找其中几个重点异常来做分析。

从前面的分析我们知道，在准备阶段本质上是不会提交事务数据的，即使发生故障也可以根据日志来进行回滚，所以不会产生数据不一致的问题，但是在提交阶段提交事务的情况下由于可能已经有参与者提交了事务数据，因此可能出现数据不一致，这个是要重点分析的阶段。

注：以下所说的参与者故障并非指全部的参与者，而是其中1个或者几个。

协调者故障&参与者正常

协调者作为系统的领导者角色，由于协调者是单点的在任何过程出现异常都需要重点处理，发生不可恢复的物理故障时，选举出新的协调者来接替之前的工作，这时新协调者就需要向所有参与者询问当前的阶段和处理进度，但是如果只是出现网络分区协调者暂时失联，就可能出现脑裂的情况。

协调者正常&参与者故障

由于协调者做决策需要依据参与者的反馈，出现参与者故障会造成协调者决策困难，如果参与者的故障是可恢复的，在短时间内恢复后则向协调者询问自己需要做什么，从而跟上节奏，如果时间过长或者是不可恢复故障，那么协调者就会回滚本次事务。

协调者故障&参与者故障(重点)

协调者在提交阶段会向所有参与者发送指令，假定在协调者发送第一条指令之后挂掉，此时只有一个参与者接收到了指令并执行后也挂掉了，其他参与者并没有收到指令。新选举出来的协调者询问所有参与节点状态时，如果已经挂掉的参与者恢复了，那么状态就明确了commit或者rollback，如果挂掉的参与者并没有恢复并且已经执行了commit/rollback操作，那么将会出现数据不一致，并且新的协调者由于没有获得足够的信息无法明确当前的状态，其他的参与者在阶段一执行后产生阻塞。

网络故障

网络分区是个很棘手的问题，极端情况下可能出现几个分区，不同分区中有独自的参与者和协调者。

综上可知，2PC协议在协调者和参与者都挂掉的时候会出现数据不一致，并且在正常的交互过程中会有阻塞情况，以及协调者单点的问题。

2PC协议的优缺点

2PC协议的原理简单，实现方便，但是存在同步阻塞、单点问题、网络分区脑裂、极端情况数据不一致的问题，我们具体展开一下。

2PC在准备阶段等待参与者响应反馈时是同步阻塞的，在实际网络中可能会导致长时间阻塞的问题，因为我们无法保证所有参与者网络的顺畅。

协调者在整个两阶段中作用很大，但是存在单点问题，一旦出现协调者故障，所有的参与者都将处于阻塞资源无法释放的情况，从而影响其他操作的进行。

2PC协议整个过程中基于所有参与者的反馈，但是由于异常情况的存在，在一些时候很难达成一致从而回滚事务，整个策略容错性不强，并且网络分区的存在可能产生脑裂造成分区数据不一致。

本文小结

本文对从单机事务和分布式事务的刚需作为切入点，描述了分布式数据一致性的难点和基本解决思路，重点阐述了2PC协议准备阶段和提交阶段的详细过程，最后对2PC协议的异常情况做出分析并给出2PC协议的优缺点。

浅谈分布式一致性协议之2PC相关推荐

浅谈分布式一致性协议之3PC
由于二阶段提交存在着诸如同步阻塞.单点问题.脑裂等缺陷.所以,研究者们在二阶段提交的基础上做了改进,提出了三阶段提交. 文章目录三阶段提交的定义 3PC的出现 3PC协议的基本过程 CanCommi ...
简述分布式一致性协议（2pc、3pc、paxos、zab）
分布式一致性协议二阶段提交协议(2pc) 三阶段提交协议(3pc) paxos zab 在分布式系统中,每个机器都可以确定自己进行的事务操作是否成功,但是无法直接了解其他机器的操作结果.因此,当一个 ...
浅谈分布式一致性算法raft
前言:在分布式的系统中,存在很多的节点,节点之间如何进行协作运行.高效流转.主节点挂了怎么办.如何选主.各节点之间如何保持一致,这都是不可不面对的问题,此时raft算法应运而生,专门用来解决上述问题 ...
浅谈分布式一致性：Raft 与 SOFAJRaft
简介: SOFAJRaft已开源作者 | 家纯来源 | 阿里技术公众号一分布式共识算法 (Consensus Algorithm) 1 如何理解分布式共识? 多个参与者针对某一件事达成完全一致 ...
浅谈分布式架构搭建-理论知识
浅谈分布式架构搭建基础理念技术选型后端技术设计总体架构设计关键案例设计架构师搭建架一般优先考虑的是安全性.稳定性.高吞吐量.哈哈,菜鸟的我让我装个B,回忆一下以前架构搭建基础理念 C ...
搞懂分布式技术16：浅谈分布式锁的几种方案
搞懂分布式技术16:浅谈分布式锁的几种方案前言随着互联网技术的不断发展,数据量的不断增加,业务逻辑日趋复杂,在这种背景下,传统的集中式系统已经无法满足我们的业务需求,分布式系统被应用在更多的场景, ...
分布式系统的一致性协议之 2PC 和 3PC
在分布式系统领域,有一个理论,对于分布式系统的设计影响非常大,那就是 CAP 理论,即对于一个分布式系统而言,它是无法同时满足 Consistency(强一致性).Availability(可用性) ...
一文说清各种分布式一致性协议
本文来说下各种常见的分布式协议文章目录概述 CAP定理 Base理论 2PC 2PC 阶段一 2PC阶段二举个例子 3PC CanCommit阶段 PreCommit阶段 doCommit阶段 ...
分布式一致性协议三部曲-深入理解一致性协议Paxos
在理解分析分布式一致性协议前,我们必须先看下CAP理论 CAP CAP是指在一个分布式系统中,一致性(Consistency).可用性(Availability).分区容错性(Partition to ...

浅谈分布式一致性协议之2PC