在微服务架构中，随着服务的逐步拆分，数据库私有已经成为共识。
随着用户访问量的逐渐上涨，数据库甚至是服务的分片、分区、水平拆分、垂直拆分已经逐渐成为较为常用的提升瓶颈的解决方案，因此越来越多的原子操作变成了跨库甚至是跨服务的事务操作。
例如一个电商应用，用户下单后需要操作订单表，库存表和用户表，如果这三个表是在同一个数据库实例中，可以放在一个事务中来保持一致性：
start transaction
insert into orders...
update inventories...
update users...
commit
如果这三个表是在三个不同的数据库实例中，又如何保证一致性呢？
分布式事务
多个副本 replica，存在不同的物理机器上。
在分布式数据库上，提交或回滚事务的决定必须统一。即要么一起提交，要么一起回滚。
2阶提交 Two Phase Commitment
准备阶段 Prepare
- 协调者（事务管理器）向所有参与者询问是否可以执行提交操作 vote，并等待各个参与者的相应。
- 参与者执行所有事务操作，并写入 redo log 和 undo log。
- 参与者相应询问：
- 若实际执行成功，返回 “同意”
- 若实际执行失败，返回 “中止”
提交阶段
-
若所有参与者都返回 “同意”：
- 协调者（事务管理器）向所有参与者发出 “正式提交” 的请求。
- 参与者收到请求后，正式提交。
- 参与者返回 “完成”。
- 协调者（事务管理器）收到所有的 “完成” 消息后，完成事务。
-
若有任何一个参与者返回 “中止”，或询问超时（即有部分参与者没有相应）：
- 协调者（事务管理器）向所有参与者发出 “回滚” 的请求。
- 参与者收到请求后，利用 undo log 进行回滚。
- 参与者返回 “回滚完成”。
- 协调者（事务管理器）收到所有的 “回滚完成” 消息后，取消事务。
缺点：
- 所有参与者都是事务阻塞的。
- 单点故障。协调者一旦故障，则无法进行。
- 数据不一致。在第二个阶段，协调者（事务管理器）向所有参与者发出 “正式提交” 或者 “回滚” 的请求，部分参与者可能由于网络问题收不到。从而导致有的参与者提交，有的没有提交。
分布式系统中的所有通信均存在着三种状态：成功，失败，超时。其中，超时状态的存在是我们在设计分布式系统时所面对的永远的痛，2PC 同样存在问题，尤其是在发送完可以提交的指令后，参与者在没有收到提交或者回滚的指令时，面对已经上锁的资源，面对已经写出去的 undo log 或者 redo log，参与者会一时陷入手足无措的状态，为了解决这个问题，3PC 应运而生。
3阶提交 Three Phase Commitment
3PC 在 commit 之前增加了 preCommit 的过程，使得在参与者在收不到确认时，依然可以从容 commit 或者 rollback，避免资源锁定太久导致浪费。但是 3PC 同样存在着很多问题。实现起来非常复杂，因为很难通过多次询问来解决系统间分歧问题，尤其是存在超时状态互不信任的分布式网络中，这也就是著名的拜占庭将军问题。
MySQL 分布式事务
XA 事务就是两阶段提交的一种实现方式。
MySQL InnoDB 存储引擎提供了对 XA 事务的支持，并通过 XA 事务来支持分布式事务的实现。
XA 事务由如下组成：
- 一个或多个资源管理器：提供访问事务资源的方法。通常一个数据库就是一个资源管理器。 例如 MySQL 数据库。
- 一个事务管理器：协调参与全局事务中的各个事务。需要和参与全局事务的所有资源管理器进行通信。 例如连接 MySQL 服务端的客户端。
- 一个应用程序：定义事务的边界，指定全局事务中的操作。
