共计 3327 个字符，预计需要花费 9 分钟才能阅读完成。
事务的概念在这篇文章中描述过，在分布式系统中，读写位于多个节点的数据，如果依旧想保证 ACID 特性，就必须实现分布式事务。而其实现关键则是适当的提交协议，目前最简洁，且使用最广泛的无疑是两阶段提交协议（2PC）。
1. 实现分布式事务关键组件
单机系统通过 事务管理器（transaction manager，TM）实现本地事务。分布式系统中，需要协调多个节点的事务管理器，共同提交成功或失败，因此需要 事务协调者（transaction coordinator，TC）。一个分布式事务管理器，可以粗略地划分为这两个子系统。这两个子系统根据自己在事务执行中扮演的角色，也可称之为 参与者 与协调者。
本地事务管理器负责本机事务并发控制和异常恢复等功能，事务协调者负责开启事务，将事务划分为多个子事务分发到相应的节点执行，并协调事务完成（一起提交成功或失败）。在实现中，TM 和 TC 可以实现在同一个进程中，也可以部署在不同的节点。
2. 经典两阶段提交协议
两阶段提交的流程比较简单。当分布式事务 T 执行完成，即事务执行的各节点都告知协调者 TC，事务已经执行完成，TC 便开启两阶段提交流程。
Phase 1 Prepare：
1.TC 写本地日志，并持久化。TC 向所有参与者发送 Prepare T 消息。
2. 各参与者 TM 收到 Prepare T 消息，根据自身情况，决定是否提交事务。
- 如果决定提交，TM 写日志并持久化，向 TC 发送 Ready T 消息。
- 如果决定不提交，TM 写日志并持久化，向 TC 发送 Abort T 消息，本地也进入事务 abort 流程。
Phase 2 Commit :
1. 当 TC 收到所有节点的回应，或者等待超时，决定事务 commit 或 abort。
- 如果所有参与者回应 Ready T，则 TC 先写日志并持久化，再向所有参与者发送 Commit T 消息。
- 如果收到至少一个参与者 Abort T 回应，或者在超时时间内有参与者未回应，则 TC 先写日志，再向所有参与者发送 Abort T 消息。
2. 参与者收到 TC 的消息后，写或日志并持久化。
两阶段提交协议可以保证分布式事务执行的一个关键点：参与者在向协调者发生 Ready T 消息前，随时都可以自己决定是否 abort，一旦这个消息发送，那么这个事务就进入 ready 状态，commit 和 abort 完全由协调者控制。Ready T 消息本质上是参与者向协调者发送的一个郑重的、不可逆的承诺。为了保证这一个承诺，参与者需要在发送 Ready T 消息前将所有必要的信息持久化，否则如果参与者在发送 Ready T 后异常宕机，重启后可能无法遵守以上承诺。在第二阶段，当协调者写了或日志，整个事务的命运就被决定了，不会再发生变化了。
为了优化 2PC 性能，减少关键路径的持久化和 RPC 次数是关键，一种对经典 2PC 的优化思路如下：
协调者无状态，不再持久化日志，但是为了方便宕机重启后恢复事务状态，需要向每个参与者发送事务的参与者名单并持久化。这样即使协调者宕机，参与者也可以方便地询问其他参与者事务状态了。该思路相当于参与者在协调者宕机时，自己担当起协调者询问事务状态的任务。
只要所有参与者 prepare 成功，事务一定会成功提交。因此为了减少提交延时，协调者可以在收到所有参与者 prepare 成功后就返回客户端成功，但如此，读请求可能会因为提交未完成而等待，从而增大读请求的延时。反过来，如果协调者确认所有参与者都提交成功才返回客户端成功，提交延时比较长，但会减少读请求延时。
3. 两阶段提交协议异常处理
两阶段提交协议的正常流程较为简单，但它还需要考虑分布式系统中各种异常问题（节点失败，网络分区等）。
1. 如果协调者检测到参与者失败：
- 如果参与者在发送 Ready T 前失败，则协调者认为该节点事务 Abort，并开始 abort 流程。
- 如果参与者在发送 Ready T 后失败，证明参与者本地事务已经持久化，协调者忽视参与者失败，继续事务流程。
2. 如果参与者在事务提交过程中失败，其恢复过程，需要根据参与者日志内容，决定本地事务状态。
- 如果日志中包含日志，证明事务已经成功提交，REDO(T)。
- 如果日志中包含日志，证明事务已经失败，UNDO(T)。
- 如果日志中包含日志，参与者 P 需向其它节点咨询当前事务状态。
- 如果协调者正常，则向告知参与者 P，事务已经 commit 或是 abort，参与者依此 REDO(T)或 UNDO(T)。
- 如果协调者异常，则向其它参与者询问事务状态。
- 如果其他参与者收到信息，并已知事务是 commit 还是 abort 状态，需回复参与者 P 事务状态。
- 如果所有的参与者现在都不知道该事务的状态（事务上下文销毁了，或者自己也处于未决状态），那么该事务处于暂时既不能 commit 也不能 abort。需要定期向其它节点问询事务状态，直到得到答案。（这是 2PC 最不想遇到的一个场景）
- 如果日志中不包含上述几种日志，说明该参与者在向协调者发送 Ready T 消息前就失败了。由于协调者没有收到参与者的回应，会超时 Abort，因此该参与者在恢复过程中，遇到这种情况也需要 abort。
3. 如果协调者在事务提交过程中失败。参与者需要根据全局事务状态（通过与其它参与者通信）决定本地行为。
（事务状态已经形成决议：）
- 如果至少有一个参与者中事务 T 已经提交（参与者包含日志），说明 T 必须要提交。
- 如果至少有一个参与者中事务 T 已经 Abort（参与者包含日志），说明 T 必须要 Abort。
（事务状态未形成决议：）
- 如果至少有一个参与者没有进入 Ready 状态（参与者不包含日志）。说明全局还未就提交与否达成协议。有两种选择：（1）等待协调者恢复。（2）参与者自行 abort。为了减少资源占用时间，选择后者居多。
- 如果所有参与者都进入了 Ready 状态，且都没有或日志（事实上，即使有这些日志，查日志也是一种比较费的操作，还需要考虑日志回收的问题），这种情况下，参与者谁都不知道现在事务的状态，只能死等协调者恢复。（又到了这个最不想遇到的场景）
当参与者均进入 ready 状态，等待协调者的下一步指令，协调者在这个时候出现异常，那么参与者将一直持有系统资源，如果基于锁实现的并发控制，还会一直持有锁，导致其他事务等待。这种情况如果持续较旧，会对系统产生巨大的影响。因此 2PC 最大的问题就是 协调者失败，可能会导致事务阻塞，未决事务的最终状态，只能等待协调者恢复后才确定。同时在这种情况下，参与者宕机重启，回放到这类未决事务，也会因为死等而 block recovery 流程。
4. 缓解 2PC blocking 思路
三阶段提交是两阶段提交的延伸，目的是解决 2PC block 的问题，但是也引入了其它问题。它的解决方式是为参与者引入 timeout 机制，如果参与者成功 PreCommit 后，一直收不到协调者最后的 DoCommit 请求，等待超时自动提交，显然这样会引入一致性问题，例如，协调者收到一个参与者 PreCommit 失败，打算发 abort 请求给其它参与者时宕机，显然此时该分布式事务应该失败，但一些参与者可能因为超时而提交。
为了解决这个问题，3PC 多引进了一个阶段，就是第一个阶段 CanCommit 阶段，协调者询问所有参与者是否可以提交，参与者如果状态正常，就会回应可以提交，但此时并不会占用任何系统资源。如果协调者及时收到了所有参与者 ok 的回应，便会认为各个参与者正常，之后的提交应该不会失败。但是实质上，仍有小概率失败的可能：某参与者 PreCommit 失败后，协调者和参与者都宕机，其它参与者超时自动提交，产生不一致。
因此 3PC 还有一个关键优化是协调者宕机后，迅速找到一个继任者，继续未完的流程，尽量保证不会出现参与者超时提交的现象。但是如果出现诸如网络分区等异常，新的协调者联系不上参与者，还是会产生一致性问题。
3PC 通过牺牲一定的 C(onsistency)来提高 A(vailability)，并且增加了网络开销，这些都是 OLTP 系统很难接受的，所以基本没有系统会采用。
但是协调者高可用，确实可以使 block 的时间大幅减少，基于诸如 Paxos/Raft 的一致性协议的高可用方案，可以让多个节点就 commit/abort 达成一致后，再去通知参与者，当协调者出现异常，可以迅速选出新的协调者，推进事务至完成。
