全文：Java-微服务下的分布式事务介绍及其解决方案-目录导航
文章目录
第五步：解决问题的方案：常见的分布式事务解决方案
常见的分布式事务解决方案
一、分布式事务分类
刚性事务：数据实时一致性，实现了ACID事务要素的事务
柔性事务：数据最终一致性，理论依据是BASE理论
在ACID事务中对一致性和隔离性的要求很高，在事务执行过程中，必须将所有的资源占用。
柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面上移至业务层面。通过放宽对强一致性和隔离性的要求，只要求当整个事务最终结束的时候，数据是一致的。而在事务执行期间，任何读取操作得到的数据都有可能被改变。这种弱一致性的设计可以用来换取系统吞吐量的提升。
二、通用解决方案
2.1、基于XA协议的两阶段提交（保证实时一致性）
XA协议最早的分布式事务模型是由X/Open国际联盟提出的X/Open Distributed Transaction Processing（DTP）模型，简称XA协议。
基于XA协议实现的分布式事务对业务侵入很小。 它最大的优势就是对使用方透明，用户可以像使用本地事务一样使用基于XA协议的分布式事务。 XA协议能够严格保障事务ACID特性。
严格保障事务ACID特性是一把双刃剑。 事务执行在过程中需要将所需资源全部锁定，它更加适用于执行时间确定的短事务。 对于长事务来说，整个事务进行期间对数据的独占，将导致对热点数据依赖的业务系统并发性能衰退明显。 因此，在高并发的性能至上场景中，基于XA协议两阶段提交类型的分布式事务并不是最佳选择。
2.1.1、两阶段提交协议（2pc：Two-Phase Commit）
一种规范，用于管理分布式事务，各主流DB厂家按此规范实现协议。(由于性能问题，目前很少使用）
第一阶段，预提交（prepare）
该阶段的主要目的在于打探数据库集群中的各个参与者是否能够正常的执行事务，具体步骤如下：
- 协调者向所有的参与者发送事务执行请求，并等待参与者反馈事务执行结果；
- 事务参与者收到请求之后，执行事务但不提交，并记录事务日志，（锁定资源）
- 参与者将自己事务执行情况反馈给协调者，同时阻塞等待协调者的后续指令。
第二阶段，事务提交（do commit）
根据第一阶段，各个参与者的执行情况，这时候存在 3 种可能性：
- 所有的参与者都回复事务执行成功。
- 一个或多个参与者回复事务执行失败。
- 协调者等待超时。
对于第 1 种情况，协调者将向所有的参与者发出提交事务的通知，具体步骤如下：
- 协调者向各个参与者发送 commit 通知，请求提交事务；
- 参与者收到事务提交通知之后执行 commit 操作，然后释放占有的资源；
- 参与者向协调者返回事务 commit 结果信息。
对于第 2 和第 3 种情况，协调者均认为参与者无法成功执行事务，为了整个集群数据的一致性，所以要向各个参与者发送事务回滚通知，具体步骤如下：
- 协调者向各个参与者发送事务 rollback 通知，请求回滚事务；
- 参与者收到事务回滚通知之后执行 rollback 操作，然后释放占有的资源；
- 参与者向协调者返回事务 rollback 结果信息。
缺点：
- 单点问题
协调者在整个两阶段提交过程中扮演着举足轻重的作用，一旦协调者所在服务器宕机，就会影响整个数据库集群的正常运行。比如在第二阶段中，如果协调者因为故障不能正常发送事务提交或回滚通知，那么参与者们将一直处于阻塞状态，整个数据库集群将无法提供服务。 - 同步阻塞
两阶段提交执行过程中，所有的参与者都需要听从协调者的统一调度，期间处于阻塞状态而不能从事其他操作，这样效率极其低下。 - 数据不一致性
两阶段提交协议虽然是分布式数据强一致性所设计，但仍然存在数据不一致性的可能性。比如在第二阶段中，假设协调者发出了事务 commit 通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了commit 操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。
针对两阶段提交存在的问题，三阶段提交协议通过引入一个 询问 阶段，以及超时策略来减少整个集群的阻塞时间，提升系统性能
2.1.2、三阶段提交协议 （3PC：Three-Phase Commit）
第一阶段，询问（can commit）
- 协调者向各个参与者发送事务询问通知，询问是否可以执行事务操作，并等待回复；
- 各个参与者依据自身状况向协调者回复一个预估值
- 如果预估自己能够正常执行事务就返回确定信息，并进入预备状态，
- 如果返回否定信息。协调者向各个参与者发出 abort 通知，终止事务
第二阶段，预提交（prepare）
- 协调者向所有的参与者发送事务执行请求，并等待参与者反馈事务执行结果；
- 事务参与者收到请求之后，执行事务但不提交，并记录事务日志，（锁定资源）
- 参与者将自己事务执行情况反馈给协调者，同时阻塞等待协调者的后续指令。
第三阶段，事务提交（do commit）
根据第二阶段参与者的执行情况，协调者向所有参与者发起提交/回滚请求。
- 全部参与者都回复“成功”，协调者才向所有参与者发起事务提交请求。
- 有一个参与者执行不成功，协调者向所有参与者发起事务回滚请求。
超时机制
协调者（TM）：三个阶段中都有超时机制：在规定时间内未收到RM的反馈，给RM发中断事务的命令;
参与者（RM）:
- 第2阶段，在规定时间内没收到TM的命令，中断事务；
- 第3阶段，在规定时间内没收到TM的命令，默认提交。
- 在本阶段如果因为协调者或网络问题，导致参与者迟迟不能收到来自协调者的 commit 或 rollback 请求，那么参与者将不会如两阶段提交中那样陷入阻塞，而是等待超时后继续 commit，相对于两阶段提交虽然降低了同步阻塞，但仍然无法完全避免数据的不一致。（实在解决不了的，采用人工补偿）
两阶段与三阶段的区别
- 在第一阶段和第二阶段 之前多了一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。但多了一层网络交互。
- 引入超时机制。同时在协调者和参与者中都引入超时机制。
- 两阶段协议在一开始就锁定资源。三阶段协议是在第一个阶段没有锁定资源。第二步才锁定资源。（综合2.3，降低了锁定资源的概率和时长，主要解决的单点故障问题，并减少阻塞。）
- 两阶段提交协议中所存在的长时间阻塞状态发生的几率还是非常低的，所以虽然三阶段提交协议相对于两阶段提交协议对于数据强一致性更有保障，但是因为效率问题，两阶段提交协议在实际系统中反而更加受宠。
MySQL中的事务提交使用的是两阶段提交：MySQL 为什么需要两阶段提交？
这个协议，提供了一个思路，后面出现的TCC模式、框架等都是在此基础上进行改进的。
2.2、利用消息队列（保证最终一致性）
2.2.1、消息队列+事件表
每个系统里都有一个事件表
create table event{
`id` bigint(20) not null comment'主键',
`event_id` bigint(20) not null comment'事件id',
`order_type` int(1) not null comment '事件类型(1:支付表支付完成，2:订单表修改状态)',
`process` varchar(32) default null comment '事件环节(1:待发送，2:已发送,3:已接收，4：已处理)',
`content` varchar(255) default null comment '事件内容，保存事件发生时需要传递的数据',
}
分为了四个步骤，每个步骤都由一个本地事务保证，是一个原子操作。
总体来看是复杂的，但是具体到某个步骤操作是比较简单的，每个步骤只需做好自己就行。并且有利于扩展，消息队列可同时对接多个其他服务。
注意点：整个事务的幂等，每个环节要紧密相扣
不适用于：数据量特别大的
改进点：每个服务都要有事件表
2.2.2、可靠消息服务
可靠消息最终一致性方案
缺点：时效性不强，但保证数据的最终一致性（如果想要及时性，还是使用tx-lcn、seata框架吧）
优势：吞吐量大、响应快、增加并发量（把整条调用链路变成了：调用单体的单个功能）
流程：
可靠消息服务所操作的事务表状态有：
- 1、待确认
- 2、已确认，待发送（向MQ发送）
- 3、已发送
- 4、已完成
- 5、取消
第一部分：支付系统到可靠消息服务
- 1-1：支付系统向可靠消息服务发送一条状态为待确认的事务消息
- 1-2：支付系统执行自己的业务逻辑，操作自己的支付表
- 1-3：根据上面的执行结果，再次调用可靠消息服务，更改之前的事务消息状态，成功则变为待发送，失败则变为取消
- 这三步是原子操作
第二部分：可靠消息服务 - 1-1-1：根据1-1的请求，将事务消息落库，此时事务消息的状态为待确认
- 1-3-1：根据1-3的请求，更改事务消息状态
- 定时任务1：向MQ发消息，将状态为待发送的消息发送给MQ，并将状态改成已发送
- 定时任务2：查一分钟前的记录，看状态还是待确认的，回查支付服务，确认状态
- 定时任务3：查状态为已发送的，长时间没变成已完成的，要再发送到MQ中
第三部分：订单服务消息MQ中的消息 - 3-1：消费MQ中的消息
- 3-2：执行本地事务，自己的业务逻辑
- 3-3：给MQ返回确认消费ACK
- 3-4：调可靠消息服务，将事务消息状态由已发送改为已完成
- 这四步是一起的，是一个原子操作
2.2.3、RocketMQ的事务消息
流程：
- 1、发送预消息（half消息）【half msg，消费者是消费不到的】
- half消息是一种特殊的消息类型，该状态的消息暂时不能被Consumer消费。当一条事务消息被成功投递到Broker上，但是Broker并没有接收到Producer发出的二次确认时，该事务消息就处于"暂时不可被消费"状态，该状态的事务消息被称为半消息。
- 2、MQ接收预消息，并返回给订单服务发送结果
- 3、根据第2步的发送结果，订单服务执行本地事务，executeLocalTransaction()
- 4、根据本地事务执行结果，订单服务向MQ发送二次确认（Commit 或是 Rollback），Broker服务端收到 Commit 状态则将半事务消息标记为可投递，订阅方最终将收到该消息；Broker服务端收到 Rollback 状态则删除半事务消息，订阅方将不会接收该消息；
- 5、回查机制（用于解决消息Commit或者Rollback发生超时或者失败的情况，checkLocalTransaction()）：
- a、在网络闪断或者是应用重启的情况下，可能导致生产者发送的二次确认消息未能到达Broker服务端，经过固定时间后，Broker服务端将会对没有Commit/Rollback的事务消息（pending状态的消息）进行“回查”；
- b、生产者收到回查消息后，检查回查消息对应的本地事务执行的最终结果；
- c、生产者根据本地事务状态，再次提交二次确认给Broker，然后Broker重新对半事务消息Commit或者Rollback；
多次回查失败，采用人工补偿
参考：
RocketMQ事务消息
2.3、最大努力通知
应用场景：服务需要调用第三方平台（它是一个开放平台），应用在第三方平台。
例如支付宝的支付业务：程序执行完后必须打印输出 success。如果商家反馈给支付宝的字符不是 success 这 7 个字符，支付宝服务器会不断重发通知，直到超过 24 小时 22 分钟。一般情况下，25 小时以内完成 8 次通知（通知的间隔频率一般是：4m,10m,10m,1h,2h,6h,15h）。
异步通知参数说明 - 支付宝文档中心 (alipay.com)
发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。具体包括：
- 有一定的消息重复通知机制。因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。
- 消息校对机制。如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。
前面介绍的的本地消息表和事务消息都属于可靠消息，与这里介绍的最大努力通知有什么不同？
可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知方来保证。
最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。
最大努力通知适用于业务通知类型，例如微信交易的结果，就是通过最大努力通知方式通知各个商户，既有回调通知，也有交易查询接口
2.4、框架
上面的两阶段提交：数据强一致性，时效性强；但并发性能不好
利用消息队列的相关方案：吞吐量大，响应快；但时效性不强(数据最终一致性)，链路长
在大多数情况下，最常用的还是两者的折中：有着不错的吞吐量性能，时效性也不错。
一些框架在传统2PC上进行改进，解决了传统 2PC长期锁资源的问题，并将分布式事务从数据库层面转到业务层面来解决（这一点上面消息队列就是很好的例子）
2.4.1、Seata
seata：Simple Extensible Autonomous Transaction Architecture
支持的事务模式: AT、TCC、SAGA、XA
官网：https://seata.io/zh-cn/
GitHub-java： https://github.com/seata/seata
Seata通过对本地关系数据库的分支事务的协调来驱动完成全局事务，无须数据库支持 XA协议，是工作在应用层的中间件。主要优点是性能较好，且不长时间占用连接资源，它以高效并且对业务0侵入的方式解决微服务场景下面临的分布式事务问题。
角色：
- Transaction Coordinator (TC)： 事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收 TM指令发起全局事务的提交与回滚，负责与RM通信协调各分支事务的提交或回滚。
- Transaction Manager ™：事务管理器，TM需要嵌入应用程序中工作，它负责开启一个全局事务，并最终向 TC发起全局提交或全局回滚的指令。
- Resource Manager (RM)： 控制分支事务，负责分支注册、状态汇报，并接收事务协调器 TC的指令，驱动分支（本地）事务的提交和回滚。
AT模式流程图：
- 1、由TM向TC注册，开启全局事务，执行自身逻辑
- 2、走到下一个RM，RM向TC注册一个分支事务，执行自身逻辑
- 3、等全部的RM都执行完了，由TM向TC发送是commit还是 rollback
- 4、TC接收到TM的消息后，异步通知所有的参与者 commit 或 rollback ，
- 5、RM收到TC的通知，回滚日志，并返回执行结果
RM的具体执行步骤：
- 1、获取本地锁 （锁定资源）
- 2、执行本地事务（sql），并记录日志（操作前后的上下文）
- 3、获取全局锁（补充：等待全局提交/回滚后，释放全局锁）
- 4、提交本地事务
- 5、释放本地锁 （释放资源）
一个全局事务执行过程中，一直持有全局锁，所以避免了【脏写】的情况。
6.4.2、TX-LCN
两三年前比较常用吧，国内开发的
支持三种事务模式：LCN模式、TCC模式、TXC模式
GitHub地址：https://github.com/codingapi/tx-lcn
文档：入门 | CodingApi
TX-LCN定位于一款事务协调性框架，框架其本身并不操作事务，而是基于对事务的协调从而达到事务一致性的效果。
角色：
- Tx-Client(TC)，普通的服务，参与者
- Tx-Manager(TM )，可以是独立的服务，也可以是参与者
LCN模式是通过代理Connection的方式实现对本地事务的操作，然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作，该代理的连接将由LCN连接池管理。
协调机制本质：代理了DataSource的机制，控制了请求和db连接的对应，还有事务的提交。将一些操作拦截下来去做额外的处理。
LCN：Lock (锁定事务单元)，Confirm (确认事务) , Notify (通知事务)
流程图：
特点:
- 该模式对代码的嵌入性为低。
- 该模式仅限于本地存在连接对象且可通过连接对象控制事务的模块。（像MySQL一样可以控制事务的）
- 该模式下的事务提交与回滚是由本地事务方控制，对于数据一致性上有较高的保障。
- 该模式缺陷在于代理的连接需要随事务发起方一共释放连接，增加了连接占用的时间。
2.4.3、TCC模式
2PC 和 3PC 都是数据库层面的，而 TCC 是业务层面的分布式事务，TCC 其实就是采用的补偿机制， 其核心思想是： 针对每个操作， 都要注册一个与其业务逻辑对应的确认和补偿（撤销） 操作。
TCC 指的是Try - Confirm - Cancel。
-
Try 指的是预留，即资源的预留和锁定，注意是预留。完成业务的准备操作
-
Confirm 指的是确认操作，这一步其实就是真正的执行了。
-
Cancel 指的是撤销操作，可以理解为把预留阶段的动作撤销了。
TCC的Confirm/Cancel阶段在业务逻辑上是不允许返回失败的，如果因为网络或者其他临时故障，导致不能返回成功，TM会不断的重试，直到Confirm/Cancel返回成功。
其实从思想上看和 2PC 差不多，都是先试探性的执行，如果都可以那就真正的执行，如果不行就回滚。
比如说一个事务要执行A、B、C三个操作，那么先对三个操作执行预留动作。如果都预留成功了那么就执行确认操作，如果有一个预留失败那就都执行撤销动作。
流程图：
-
1、由链路的第一个服务（发起方）向事务协调器开启全局事务，执行自身逻辑
-
2、走到下一个服务，服务向事务协调器注册一个分支事务，执行自身逻辑
-
3、等全部的RM都执行完了，由TM向TC发送是commit还是 rollback
-
4、事务协调者接收到发起方的消息后，异步通知所有的参与者 commit 或 rollback ，
-
5、参与者收到事务协调者的通知，执行对应的confirm()方法 或者 cancel() 方法，并返回结果
TCC特点如下：
- 并发度较高，无长期资源锁定。
- 开发量较大，需要提供Try/Confirm/Cancel接口，TCC 属于应用层的一种补偿方式， 所以需要程序员在实现的时候多写很多补偿的代码， 在一些场景中， 一些业务流程可能用 TCC 不太好定义及处理。
- 一致性较好，重试可以保证Confirm() / Cancel() 一定会执行成功
- TCC适用于订单类业务，对中间状态有约束的业务
适用的场景：有用到不支持本地事务的存储数据的工具，比如mangodb。
异常情况：
-
空回滚：Try未执行，Cance执行。
- 原因：当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行Try阶段，当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。
-
幂等：多次执行cancel() 或者 confirm()。
- 原因：在重试过程中，实际重试成功了，但是由于网络原因，协调者没接收到重试成功的消息，再次去执行重试。
-
悬挂：Cancel在Try之前执行。
- 原因：在 RPC 调用分支事务try时，此时网络发生拥堵，超过一定时间后协调者认为其执行出错了，通知其回滚该分布式事务，可能回滚完成后。Try 的 RPC 请求才到达参与者真正执行。
解决方法：各家建议的方案都是业务方通过唯一键，去查询相关联的操作是否已完成，如果已完成则直接返回成功。相关的判断逻辑较复杂，易出错，业务负担重。
2.5、小结
有两点要关注：
1、日志记录
2、补偿机制
无论哪种方案，都不能百分百保证不会出现问题，所有都要有补偿机制（人工补偿、代码兜底）
鸵鸟算法：忽略那些发生概率很低的问题
不要为了极低概率的事件去增加系统的复杂度，如果要解决性价比不高，后面通过人工补偿，或者其他补偿机制去调整就好了。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
