Dubbo两阶段提交协议

古城微笑少年丶 2024-03-17 10:05 23阅读 0赞

**两阶段提交协议**

两阶段提交协议是一种经典的强一致性中心化副本控制协议。虽然在工程中该协议有 较多的问题，但研究该协议能很好的理解分布式系统的几个典型问题。

**流程描述**

两阶段提交协议是一种典型的“中心化副本控制”协议。在该协议中，参与的节点分 为 两 类 ： 一 个 中 心 化 协 调 者 节 点 （ coordinator

） 和 N 个 参 与 者 节 点 （participant）。每个参与者节点即上文背景介绍中的管理数据库副本的节点。

两阶段提交的思路比较简单，在第一阶段，协调者询问所有的参与者是否可以提交事 务（请参与者投票），所有参与者向协调者投票。在第

二阶段，协调者根据所有参与 者的投票结果做出是否事务可以全局提交的决定，并通知所有的参与者执行该决定。 在一个两阶段提交流程

中，参与者不能改变自己的投票结果。两阶段提交协议的可以 全局提交的前提是所有的参与者都同意提交事务，只要有一个参与者投票选择

放弃 (abort)事务，则事务必须被放弃。

流程：两阶段提交协调者流程

1. 写本地日志“begin\_commit”，并进入WAIT 状态；

2. 向所有参与者发送“prepare 消息”；

3. 等待并接收参与者发送的对“prepare 消息”的响应；3.1 若收到任何一个 参与者发送的“vote-abort 消息”；3.1.1 写本地“global-abort”

日志，进 入ABORT；3.1.2 向所有的参与者发送“global-abort 消息”；3.1.3 进入 ABORT 状态；3.2 若收到所有参与者发送的“vote

commit”消息；3.2.1 写 本地“global-commit”日志，进入COMMIT 状态；3.1.2 向所有的参与者发 送“global-commit 消息”； 4. 等待并

接收参与者发送的对“global-abort 消息”或“global-commit 消 息”的确认响应消息，一旦收到所有参与者的确认消息，写本 地

“end\_transaction” 日志流程结束。

流程：两阶段提交协调者流程

1. 写本地日志“init”记录，进入INIT 状态

2. 等待并接受协调者发送的“prepare 消息”，收到后 2.1 若参与者可以提交 本次事务 2.1.1 写本地日志“ready”，进入READY 状态 2.1.2

向协调者发 送“vote-commit”消息 2.1.4 等待协调者的消息2.1.4.1 若收到协调者 的“global-abort”消息2.1.4.1.1 写本地日志“abort”，进

入ABORT 状态 2.1.4.1.2 向协调者发送对“global-abort”的确认消息 2.1.4.2 若收到协调者 的“global-commit”消息2.1.4.1.1 写本地日

志“commit”，进入COMMIT 状态 2.1.4.1.2 向协调者发送对“global-commit”的确认消息 2.2 若参与 者无法提交本次事务 2.2.1 写本

地日志“abort”，进入ABORT 状态 2.2.2 向协调者发送“vote-abort”消息 2.2.3 流程对该参与者结束 2.2.4 若后续收到 协调者的“global

abort”消息可以响应

3. 即使流程结束，但任何时候收到协调者发送的“global-abort”消息 或“global-commit”消息也都要发送一个对应的确认消息。

**异常处理**

宕机恢复

1. 协调者宕机恢复 协调者宕机恢复后，首先通过日志查找到宕机前的状态。如 果日志中最后是“begin\_commit”记录，说明宕机前协调者

处于WAIT 状态， 协调者可能已经发送过“prepare 消息”也可能还没发送，但协调者一定还没 有发送过“global-commit 消息”或“global

abort 消息”，即事务的全局状 态还没有确定。此时，协调者可以重新发送“prepare 消息” 继续两阶段提交 流程，即使参与者已经发送

过对“prepare 消息”的响应，也不过是再次重传 之前的响应而不会影响协议的一致性。如果日志中最后是“globalcommit”或“global

abort”记录，说明宕机前协调者处于COMMIT 或 ABORT 状态。此时协调者只需重新向所有的参与者发送“global-commit 消 息”或

“global-abort 消息”就可以继续两阶段提交流程。

2. 参与者宕机恢复参与者宕机恢复后，首先通过日志查找宕机前的状态。如果 日志中最后是“init”记录，说明参与者处于INIT 状态，还没

有对本次事务做 出投票选择，参与者可以继续流程等待协调者发送的“prepare 消息”。如果 日志中最后是“ready”记录，说明参与者处

于REDAY 状态，此时说明参与者 已经就本次 事务做出了投票选择，但宕机前参与者是否已经向协调者发 送“vote-commit”消息并不可

知。所以此时参与者可以向协调者重发“votecommit”，并继续协议流程。如果日志中最后是“commit”或“abort”记 录，说明参与者已经

收到过协调者的“global-commit 消息”（处于COMMIT 状态）或者“global-abort 消息”（处于ABORT 状态）。至于是否向协调者 发 送

过对“global-commit”或“global-abort”的确认消息则未知。但即使 没有发送过确认消息，由于协调者会不断重发“global-commit”或

“globalabort”，只需在收到这些消息时发送确认消息既可，不影响协议的全局一致 性。

**协议分析**

两阶段提交协议在工程实践中真正使用的较少，主要原因有以下几点：

1. 两阶段提交协议的容错能力较差。从上文的分析可以看出，两阶段提交协议 在某些情况下存在流程无法执行下去的情况，且也无法判

断流程状态。在工程 中好的分布式协议往往总是可以在即使发生异常的情况下也能执行下去。例 如，回忆Lease 机制（2.3 ），一旦

lease 发出，无论出现任何异常，Lease 服 务器节点总是可以通过时间判定出Lease 是否有效，也可以用等待Lease 超时 的方法收回

Lease 权限，整个Lease 协议的流程不存在任何流程被阻塞而无法 执行下去的情况。与Lease 机制的简单有效相比，两阶段提交的协议

显得较为 复杂且容错能力差。

2. 两阶段提交协议的性能较差。一次成功的两阶段提交协议流程中，协调者与 每个参与者 之间至少需要两轮交互4 个消息“prepare”、

“votecommit”、“global-commit”、“确认global-commit”。过多的交互次 数会降低性能。另一方面，协调者需要等待所有的参与者的

投票结果，一旦存 在较慢的参与者，会影响全局流程执行速度。

虽然存在一些改进的两阶段提交协议可以提高容错能力和性能，然而这类协议依旧是 在工程中使用较少的一类协议，其理论价值大于实践意

义。

**MVCC**

MVCC(Multi-version Cocurrent Control，多版本并发控制)技术。MVCC 技术最初 也是在数据库系统中被提出，但这种思想并不局限于单机

的分布式系统，在分布式系 统中同样有效。

MVCC 即多个不同版本的数据实现并发控制的技术，其基本思想是为每次事务生成 一个新版本的数据，在读数据时选择不同版本的数据即可

以实现对事务结果的完整性 读取。在使用MVCC 时，每个事务都是基于一个已生效的基础版本进行更新，事务可 以并行进行，从而可以产生

一种图状结构。基础数据的版本为1，同时产生了两个事务：事务A 与事务B。这两个事务都各自对数 据进行了一些本地修改（这些修改只有事务自己可见，

不影响真正的数据），之后事 务A 首先提交，生成数据版本2；基于数据版本2，又发起了事务C，事务C 继续提 交，生成了数据版 本3；最

后事务B 提交，此时事务B 的结果需要与事务C 的结果合 并，如果数据没有冲突，即事务 B 没有修改事务A 与事务C 修改过的变量，那么事

务 B 可以提交，否则事务B 提交失败。MVCC 的流程过程非常类似于SVN 等版本控制 系统的流程，或者说SVN 等版本控制系统就是 使用的

MVCC 思想。事务在基于基础 数据版本做本地修改时，为了不影响真正的数据，通常有两种做法，一是将基础数据 版本中的数据完全拷贝出

来再修改，SVN 即使用了这种方法，SVN check out 即是 拷贝的过程；二是每个事务中只记录更新操作，而不记录完整的数据，读取数据时

再 将更新操作应用到用基础版本的数据从而计算出结果，这个过程也类似SVN 的增量提 交。

**Paxos****协议**

Paxos 协议是少数在工程实践中证实的强一致性、高可用的去中心化分布式协议。 Paxos 协议的流程较为复杂，但其基本思想却不难理解，

类似于人类社会的投票过程。Paxos 协议中，有一组完全对等的参与节点（称为accpetor），这组节点各自就某一事件做出决议，如果某个

决议获得了超过半数节点的同意则生效。Paxos 协议中只要有超过一半的节点正常，就可以工作，能很好对抗宕机、网络分化等异常情况。

角色

Proposer：提案者。Proposer 可以有多个，Proposer 提出议案（value）。所谓 value，在工程中可以是任何操作，例如“修改某个变量的

值为某个值”、“设置当前primary 为某个节点”等等。Paxos 协议中统一将这些操作抽象为value。不同的 Proposer 可以提出不同的甚至矛盾

的value，例如某个Proposer 提议“将变量X 设置为1”，另一个Proposer 提议“将变量X 设置为2”，但对同一轮Paxos 过程，最多只有一个

value 被批准。Acceptor：批准者。Acceptor 有N 个，Proposer 提出的value 必须获得超过半数(N/2+1)的Acceptor 批准后才能通过。

Acceptor 之间完全对等独立。Learner：学习者。Learner 学习被批准的value。所谓学习就是通过读取各个Proposer 对value 的选择结

果，如果某个value 被超过半数Proposer 通过，则Learner 学习到了这个value。回忆（2.4 ） 不难理解，这里类似Quorum 机制，某个

value 需要获得W=N/2 + 1 的Acceptor 批准，从而学习者需要至少读取N/2+1 个Accpetor，至多读取N 个Acceptor 的结果后，能学习到一

个通过的value。上述三类角色只是逻辑上的划分，实践中一个节点可以同时充当这三类角色。

流程

Paxos 协议一轮一轮的进行，每轮都有一个编号。每轮Paxos 协议可能会批准一个 value，也可 能无法批准一个value。如果某一轮Paxos

协议批准了某个value，则以后各轮Paxos 只能批准这个 value。上述各轮协议流程组成了一个Paxos 协议实例，即一次Paxos 协议实例只能

批准一个value，这也是Paxos 协议强一致性的重要体现。每轮Paxos 协议分为阶段，准备阶段和批准阶段，在这两个阶段Proposer 和

Acceptor 有各自的处理流程。

流程：Proposer 的流程 （准备阶段）

1. 向所有的Acceptor 发送消息“Prepare(b)”；这里b 是Paxos 的轮数，每

轮递增

2. 如果收到任何一个Acceptor 发送的消息“Reject(B)”，则对于这个 Proposer 而言本轮Paxos 失败，将轮数b 设置为B+1 后重新步骤1；

（批准阶段，根据收到的Acceptor 的消息作出不同选择）

3. 如果接收到的Acceptor 的“Promise(b, v\_i)”消息达到N/2+1 个（N 为 Acceptor 总数，除法取整， 下同）；v\_i 表示Acceptor 最近一次

在i 轮批准过 value v。3.1 如果收到的“Promise(b, v)”消息中，v 都为空，Proposer 选择一个value v，向所有Acceptor 广播Accept(b,

v)；3.2 否则，在所有收到的“Promise(b, v\_i)”消息中，选择i 最大的value v，向所有Acceptor 广播消息Accept(b，v)；

4. 如果收到Nack(B)，将轮数b 设置为B+1 后重新步骤1；流程：Accpetor 流程 （准备阶段）

5. 接受某个Propeser 的消息Prepare(b)。参数B 是该Acceptor 收到的最大

Paxos 轮数编号；V 是Acceptor 批准的value，可以为空 1.1 如果b>B，回复 Promise(b, V\_B)，设置B=b; 表示保证不再接受编号小于b 的提

案。1.2 否则，回复Reject(B) （批准阶段）

2. 接收Accept(b, v)， 2.1 如果b < B, 回复Nack(B)，暗示proposer 有一个更大编号的提案被这个Acceptor 接收了 2.2 否则设置V=v。表示

这个Acceptor 批准的Value 是v。广播Accepted 消息。

例子

基本例子里有5 个Acceptor，1 个Proposer，不存在任何网络、宕机异常。我们着重考察各个Accpetor 上变量B 和变量V 的变化，及

Proposer 上变量b 的变化。

1. 初始状态2. Proposer 向所有Accpetor 发送“Prepare(1)”，所有Acceptor 正确处理，并回复Promise(1, NULL

3. Proposer 收到5 个Promise(1, NULL)，满足多余半数的Promise 的value 为空，此时发送 Accept(1, v1)，其中v1 是Proposer 选择的

Value。

4. 此时，v1 被超过半数的Acceptor 批准，v1 即是本次Paxos 协议实例批准的

Value。如果Learner 学习value，学到的只能是v1

在同一个Paxos 实例中，批准的Value 是无法改变的，即使后续Proposer 以更高的序号发起Paxos 协议也无法改变value。Paxos 协议的核

心就在于“批准的value 无法改变”，这也是整个协议正确性的基础。

Paxos 协议是被人为设计出来，其设计过程也是协议的推导过程。Paxos 协议利用了 Quorom 机 制，选择的W=R=N/2+1。简单而言，协议

就是Proposer 更新 Acceptor 的过程，一旦某个Acceptor 成功更新了超过半数的Acceptor，则更新成功。Learner 按Quorum 去读取

Acceptor，一旦某个value 在超过半数的Proposer 上被成功读取，则说明这是一个被批准的value。协议通过引入轮次，使得高轮次的提议

抢占低轮次的提议来避免死锁。协议设计关键点是如何满足“在一次Paxos 算法实例过程中只批准一个Value”这一约束条件。

**CAP**

CAP 理论的定义很简单，CAP 三个字母分别代表了分布式系统中三个相互矛盾的属性：

Consistency (一致性)：CAP 理论中的副本一致性特指强一致性（1.3.4 ）；

Availiablity(可用性)：指系统在出现异常时已经可以提供服务；

Tolerance to the partition of network (分区容忍)：指系统可以对网络分区（1.1.4.2 ）这种异常情 况进行容错处理；

CAP 理论指出：无法设计一种分布式协议，使得同时完全具备CAP 三个属性，即1) 该种协议下的副本始终是强一致性，2)服务始终是可用

的，3)协议可以容忍任何网络分区异常；分布式系统协议只能在CAP 这三者间所有折中。热力学第二定律说明了永动机是不可能存在的，不

要去妄图设计永动机。与之类似， CAP 理论的意义就在于明确提出了不要去妄图设计一种对CAP 三大属性都完全拥有的完美系统，因为这种

系统在理论上就已经被证明不存在。

Lease 机制: Lease 机制牺牲了部分异常情况下的A，从而获得了完全的C 与很好的P。

Quorum 机制: Quorum 机制，在CAP 三大因素中都各做了折中，有一定的C，有较好 的A，也有较好的P，是一种较为平衡的分布式协

议。

两阶段提交协议: 两阶段提交系统具有完全的C，很糟糕的A，很糟糕的P。

Paxos 协议：同样是强一致性协议，Paxos 在CAP 三方面较之两阶段提交协议要优秀得多。Paxos 协议具有 完全的C，较好的A，较好

的P。Paxos 的A 与P 的属性与Quorum 机制类似，因为Paxos 的协议本 身就具有Quorum 机制的因素。

Dubbo两阶段提交协议

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 Dubbo两阶段提交协议

相关深入理解分布式技术 - 彻底搞懂两阶段提交协议和三阶段提交协议

相关 flink 两阶段提交协议 2pc

相关分布式事务一致性-XA两阶段提交协议

相关两阶段提交协议

相关分布式学习——关于分布式事务、两阶段提交协议、三阶提交协议

相关关于分布式事务、两阶段提交协议、三阶提交协议

相关 [分布式]：关于分布式事务、两阶段提交协议、三阶提交协议

相关关于分布式事务、两阶段提交协议、三阶提交协议

相关关于分布式事务、两阶段提交协议、三阶提交协议