对于银行系统来说，以上 2 种情况都是「不允许发生」，此时就需要事务来保证转账操作的成功。
在「单体应用」中，我们只需要贴上@Transactional注解就可以开启事务来保证整个操作的「原子性」。
但是看似以上简单的操作，在实际的应用架构中，不可能是单体的服务，我们会把这一系列操作交给「N个服务」去完成，也就是拆分成为「分布式微服务架构」。
比如下订单服务，扣库存服务等等，必须要「保证不同服务状态结果的一致性」，于是就出现了分布式事务。
分布式理论
CAP定理
在一个分布式系统中，以下三点特性无法同时满足，「鱼与熊掌不可兼得」
具体地讲在分布式系统中，在任何数据库设计中，一个Web应用「至多只能同时支持上面的两个属性」。显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。
BASE理论
在分布式系统中，我们往往追求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢？
前人已经给我们提出来了另外一个理论，就是BASE理论，它是用来对CAP定理进行进一步扩充的。BASE理论指的是：
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
分布式事务解决方案
两阶段提交（2PC）
熟悉mysql的同学对两阶段提交应该颇为熟悉，mysql的事务就是通过「日志系统」来完成两阶段提交的。
两阶段协议可以用于单机集中式系统，由事务管理器协调多个资源管理器；也可以用于分布式系统，「由一个全局的事务管理器协调各个子系统的局部事务管理器完成两阶段提交」。
这个协议有「两个角色」，
A节点是事务的协调者，B和C是事务的参与者。
事务的提交分成两个阶段
第一个阶段是「投票阶段」
第二个阶段是「决定阶段」
当A节点收到B和C参与者所有的确认消息后
可能会存在哪些问题？
三阶段提交（3PC）
三阶段提交又称3PC，相对于2PC来说增加了CanCommit阶段和超时机制。如果段时间内没有收到协调者的commit请求，那么就会自动进行commit，解决了2PC单点故障的问题。
但是性能问题和不一致问题仍然没有根本解决。下面我们还是一起看下三阶段流程的是什么样的？
补偿事务（TCC）
TCC其实就是采用的补偿机制，其核心思想是：「针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作」。它分为三个阶段：
「Try,Confirm,Cancel」
比如下一个订单减一个库存：
执行流程：
TCC 事务机制相比于上面介绍的2PC，解决了其几个缺点：
总之，TCC 就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，并且很大程度的「增加」了业务代码的「复杂度」，因此，这种模式并不能很好地被复用。
本地消息表
消息事务
消息事务的原理是将两个事务「通过消息中间件进行异步解耦」，和上述的本地消息表有点类似，但是是通过消息中间件的机制去做的，其本质就是'将本地消息表封装到了消息中间件中'。
执行流程：
这种方案也是实现了「最终一致性」，对比本地消息表实现方案，不需要再建消息表，「不再依赖本地数据库事务」了，所以这种方案更适用于高并发的场景。目前市面上实现该方案的「只有阿里的 RocketMQ」。
最大努力通知
最大努力通知的方案实现比较简单，适用于一些最终一致性要求较低的业务。
执行流程：
Sagas 事务模型
Saga事务模型又叫做长时间运行的事务
其核心思想是「将长事务拆分为多个本地短事务」，由Saga事务协调器协调，如果正常结束那就正常完成，如果「某个步骤失败，则根据相反顺序一次调用补偿操作」。
Seata框架中一个分布式事务包含3种角色：
「Transaction Coordinator (TC)」：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。「Transaction Manager (TM)」：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。「Resource Manager (RM)」：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。
seata框架「为每一个RM维护了一张UNDO_LOG表」，其中保存了每一次本地事务的回滚数据。
具体流程：1.首先TM 向 TC 申请「开启一个全局事务」，全局事务「创建」成功并生成一个「全局唯一的 XID」。
2.XID 在微服务调用链路的上下文中传播。
3.RM 开始执行这个分支事务，RM首先解析这条SQL语句，「生成对应的UNDO_LOG记录」。下面是一条UNDO_LOG中的记录，UNDO_LOG表中记录了分支ID，全局事务ID，以及事务执行的redo和undo数据以供二阶段恢复。
4.RM在同一个本地事务中「执行业务SQL和UNDO_LOG数据的插入」。在提交这个本地事务前，RM会向TC「申请关于这条记录的全局锁」。
如果申请不到，则说明有其他事务也在对这条记录进行操作，因此它会在一段时间内重试，重试失败则回滚本地事务，并向TC汇报本地事务执行失败。
6.RM在事务提交前，「申请到了相关记录的全局锁」，然后直接提交本地事务，并向TC「汇报本地事务执行成功」。此时全局锁并没有释放，全局锁的释放取决于二阶段是提交命令还是回滚命令。
7.TC根据所有的分支事务执行结果，向RM「下发提交或回滚」命令。
总结
本文介绍了分布式事务的一些基础理论，并对常用的分布式事务方案进行了讲解。
分布式事务本身就是一个技术难题，业务中具体使用哪种方案还是需要不同的业务特点自行选择，但是我们也会发现，分布式事务会大大的提高流程的复杂度，会带来很多额外的开销工作，「代码量上去了，业务复杂了，性能下跌了」。
所以，当我们真实开发的过程中，能不使用分布式事务就不使用。
本文分享自微信公众号 - Java中文社群（javacn666）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。