分布式事务

二将军问题

一支白军被围困在一个山谷中，山谷的左右两侧是蓝军。困在山谷中的白军人数多余山谷两侧的任意一支蓝军，而少于两支蓝军的之和。若一支蓝军对白军单独发起进攻，则必败无疑；但若两支蓝军同时发起进攻，则可取胜。两只蓝军的总指挥位于山谷左侧，他希望两支蓝军同时发起进攻，这样就要把命令传到山谷右侧的蓝军，以告知发起进攻的具体时间。假设他们只能派遣士兵穿越白军所在的山谷（唯一的通信信道）来传递消息，那么在穿越山谷时，士兵有可能被俘虏。

类似的问题在计算机网络中普遍存在，比如微服务 A 调用另一个微服务 B，从微服务 A 的调用结果来看，无非是成功、超时和失败，其中失败是由于微服务 B 内部出现错误，而超时有可能因为 A 到 B 的网络问题，微服务 B 在返回之前宕机或 B 到 A 的网络问题。

二阶段提交 2PC

2PC 是一种实现分布式事务的协议，在 2PC 中有一个事务协调者和多个事务参与者，事务参与者负责执行事务操作，而事务协调者负责协调事务参与者来保证分布式事务的原子性。2PC 要求事务参与者实现 Prepare、Commit 和 Rollback 三个接口，其中当事务协调者调用事务参与者的 Prepare 接口时，事务参与者会执行本地事务到待提交状态（待提交状态指的是接下来可以进行提交或回滚，而不会出现任何错误）。
2PC 分为两个阶段：

1. 准备阶段：事务协调者调用各个事务参与者的 Prepare 接口，各个事务参与者会各自执行本地事务到待提交状态，事务协调者会收到所有事务参与者的结果，包括成功、失败和超时。
2. 提交阶段：在收到所有事务参与者的结果后，如果存在任何失败或超时则调用所有事物参与者的 Rollback 接口进行回滚，如果所有事物参与者的 Prepare 接口都成功了，则事物协调者会调用所有事物参与者的 Commit 接口进行提交。

可以将这三个接口简单地（但不严谨地）理解成 XA 协议。

2PC 缺点

1. 同步阻塞：在准备阶段，事物参与者会执行本地事务到待提交状态，本地事务执行时上的锁直到提交阶段才可以释放，而进入提交阶段需要等待所有事物参与者的 Prepare 接口返回。
2. 单点故障：准备阶段完成后如果事务协调者宕机，则所有事务参与者会长期开启事务

TCC 方案

TCC 本质是一个应用层面的 2PC，TCC 是 Try、Confirm、Cancel 三个词的缩写，分别对应 Prepare、Commit 和 Rollback 三个接口。2PC 和 TCC 看起来很像，但还有一些细微的差别。

1. 2PC 是偏数据库层面的，而 TCC 是纯业务层面。
2. TCC 要求 Confirm 和 Cancel 接口实现幂等性，这样在提交阶段如果出现超时就可以不断重试。
3. TCC 中 Try 接口可以只进行资源的预留，而不执行真正的业务逻辑，将真正的业务逻辑放在 Confirm 阶段执行。在 TCC 事务机制中认为，如果在 Try 阶段能正常的预留资源，那 Confirm 一定能完整正确的提交。这一点其实解决了 2PC 的同步阻塞问题，即任何事务参与者不再需要等待所有事务参与者的业务执行完成。

Seata

Seata 是一个开源分布式事务框架，提供了 AT、TCC、SAGA 和 XA 事务模式。其中 AT 模式是 Seata 主推的事务模式，使用 AT 要求微服务使用的数据库必须是支持事务的关系型数据库。
Seata 的 AT 模式建立在关系型数据库的本地事务特性的基础之上，在 Prepare 接口中，AT 模式在执行本地事务时，除了进行业务数据操作，还会将修改前和修改后的数据组成一个回滚日志插入到 Seata 自己维护的一个表中，最后直接提交事务。对于 Commit 接口，直接异步删除回滚日志即可。对于 Rollback 接口，则通过 Seata 的回滚日志进行反向补偿。
Seata 之所以更加高效在于它在 Prepare 阶段就提交了事务，释放了本地事务产生的锁。但正因为提交了事务，所以需要 Seata 额外维护一个表来记录回滚日志。