前言
最近业务变动准备面试，看了一下别人的面试情况，都问了关于分布式事务的问题。所以今天整理一下。
分布式事务解决方案
1. XA 方案（两阶段提交方案）
- 支持的场景：一个服务操作多个数据库，要求事务跨数据库保持一致性
- 实现原理：事务管理器（服务器）对多个资源管理器（数据库）发起事务，多个资源管理器完成事务任务后先不进行 commit 操作，事务管理器检查所有资源管理器上的事务是否都能够完成并都处于待提交状态。如果有至少一个文件管理器无法完成被分配的事务任务，则事务管理器通知全部文件管理器进行回滚。如果全部文件管理器都进入了待提交状态，则事务管理器发起提交请求，让资源管理器提交各自的事务。
- 优点：通过事务管理器本身支持的事务性操作来实现回滚操作，业务侧实现比较简单。
- 缺点：一个服务操作多个数据库的场景，现在几乎不存在。现在的服务基本都是微服务的形式，每个服务只有自己的一个数据库或者没有数据库。如果一个服务操作多个数据库，那么除了操作自己的数据库还要操作别人的数据库，那就乱套了。别人的数据库是不可能让你操作的。
2. TCC 方案（Try - Confirm / Cancel）
- 支持的场景：TCC 方案可以支持强一致性的分布式事务，适合于银行转账等要求强一致性的场景
- 实现原理：事务分为三个阶段，即 T - C - C。首先是 Try 阶段通知所有参与的服务器检查资源并且锁定资源，如果全部服务器都可以正常执行 try，则执行 confirm 操作，即让参与的服务器执行各自的操作，如果有一个服务器无法满足 try 执行的条件，则向其他服务器发送 cancel 命令，撤回对资源的锁定。
- 示例：银行账户 A 转账 100 元到账户 B，且这两个账户分别隶属于服务器①和服务器②，事务发起的服务器记作服务器③。try 阶段：服务器③向服务器①②发送 try 指令，服务器①锁定 A 账户并检查 A 账户余额是否大于等于 100，服务器②锁定 B 账户。confirm 阶段：如果 try 阶段无异常，则服务器③向服务器①②发送 confirm 指令，服务器①将 A 账户余额减去 100 并保存，服务器②向 B 账户增加 100。 如果 try阶段不能正确执行，比如 A 账户余额只有 90 了，则执行 cancel 命令，释放锁定的 AB 账户。
- 优点：强一致性，确保完全的事务完整性
- 缺点：所有事务操作代码，例如回滚，都需要业务侧自行编写，极大增加了开发难度。另外，由于网络问题，try-confirm-cancel 信号可能受到影响，会出现诸多问题，例如，没有收到 try 就收到了 cancel 那么服务器必须支持空回滚，或者收到了两次 confirm，则要求服务器支持幂等操作。
3. 可靠消息最终一致性方案
- 支持场景：没有强一致性要求，只要求最终一致性的场景，例如账单支付和商品发货，账单支付后，无需同时进行商品发货只要最终商品可以发货就行
- 实现原理： 例如服务器A 支持账单支付，服务器 B 支持商品发货，服务器 A 在执行账单支付之前发送一条 prepare 到消息队列，如果发送失败，则服务器 A 立即取消后续操作，如果发送成功，则服务器 A 继续支付操作，支付成功则发送成功消息给消息队列，支付失败则发送失败消息给消息队列。如果是成功的消息，则服务器 B 马上执行发货操作，如果失败则一直重试，直到成功或者超时。如果 B 超时未完成，则想办法通知 A 回滚，或者发送报警消息进行人工回滚。
- 优点：简单高效易于实现，能够实现最终一致性
- 缺点：无法实现强一致性
