分布式事务常见解决方案与最终一致性
文章目录
分布式事务产生背景
数据库水平拆分
微服务拆分
分布式事务解决方案
TCC
XA事务(2PC)
最终一致性(消息事务)
错误场景一
错误场景二
错误场景三
解决方案对比
最终一致性-本地消息表
最终一致性-RocketMq事务消息
两阶段提交
事务状态定时回查
事务消息核心
最后
参考资料
分布式事务产生背景
数据库水平拆分
业务发展初期，许多业务采用单库单表的方案来存储数据。随着业务的不断演进、发展，存储数据量不断变大，写入QPS不断增加，单库的存储、写入都会存在瓶颈。因此我们对数据库进行水平拆分，即将完整的数据集，通过一定规则(比如按userId，orderId取模)，将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中。如下图所示
数据库水平拆分后，引来了如下几个问题
1. 跨库查询较为复杂，如跨库join性能差
2. 原本往一个数据库中写入数据，现在可能变为往多个库中同时写入数据，这就是跨库分布式事务问题
微服务拆分
在早期的一些系统中，不同业务模块耦合在一个大的业务系统里，随着业务的发展，单个业务系统扩展性差，耦合度高的缺点越来越明显。因此将不同业务模块进行拆分，构建为松耦合、可独立部署的一组服务。不同业务系统间通过诸如Dubbo、Spring Cloud等微服务框架进行通信。
如图所示，拆分后的业务应用，是一个单一的、可独立部署的组件，不同业务服务之间松耦合，可拓展。
随着服务的拆分，分布式事务问题也不可避免，服务拆分之前，在单JVM进程中可以通过Spring事务保证对单库、多个业务表的操作在一个事务中。业务系统按照服务拆分之后，一个完整的业务操作往往需要通过Rpc调用多个服务，如何保证多个服务间的数据一致性成为一个难题
分布式事务解决方案
TCC
TCC模式分布式事务解决方案，需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作，事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。
是一种应用层面侵入业务的两阶段提交，每个操作含义如下
操作方法 |
含义 |
Try |
完成数据检查(一致性)，预留资源(隔离性) |
Confirm |
确认执行业务操作，只使用try阶段预留的资源，需保证幂等 |
Cancel |
取消业务操作，释放预留资源，需保证幂等 |
TCC模式的架构图如下
执行步骤如下：
1. 主业务服务负责发起并完成整个事务操作。
2. 从业务服务提供TCC型业务操作。
3. 业务活动管理器(事务协调者)控制业务活动的一致性，它登记业务活动中的操作，并在业务活动提交时进行confirm操作，在业务活动取消时进行cancel操作，协调者会通过不断重试的机制保障从业务的commit/cancel操作一定会执行，故需保证TCC接口的幂等性
TCC方案也有不足之处，表现在以下几个方面：
1. 对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。
2. 实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必须实现幂等
3. 需要注意极端情况下的空回滚、防悬挂控制，对开发者/TCC中间件有较高要求
市面上的TCC中间件有：tcc-transaction
XA事务(2PC)
XA事务利用事务资源（比如Oracle、DB2这些商业数据库）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种事务模式，需要引入事务管理器作为分布式事务的全局协调者
如图所示，XA协议是一种特殊的两阶段提交协议，分为两个阶段
1. 执行阶段：
可回滚：业务 SQL 操作放在 XA 分支中进行，由资源对 XA 协议的支持来保证可回滚
持久化：XA 分支完成后，执行 XA prepare，同样，由资源对 XA 协议的支持来保证持久化（即，之后任何意外都不会造成无法回滚的情况）
2. 完成阶段：
分支提交：执行 XA 分支的 commit
分支回滚：执行 XA 分支的 rollback
缺点：XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想
目前市面上也出现了支持XA事务编程模型的中间件：Seata
同时Seata还支持一种特殊定制化，基本零侵入业务的AT模式(一种演进版本的2PC模式)
最终一致性(消息事务)
大部分的业务场景中，其实并不一定非得强求数据的强一致性，比如用户在A系统进行签到，那么在B系统里进行计算绩效，只需保证A签到成功后，B系统绩效一定会计算,至于什么时候计算,是否立马计算,其实并不重要。
其他诸如用户在A系统下了单，在B系统用户的积分一定得增加这种场景都是类似的，最终一致性也是解决分布式事务的一种常见方案。
很多场景下，我们“发消息”这个过程，目的往往是通知另外一个系统或者模块去更新数据，消息队列中的“事务”，主要解决消息生产者和消息消费者的数据一致性问题。
消息方案从本质上讲是将分布式事务转换为多个本地事务，然后依靠下游业务的重试机制达到最终一致性。基于消息的最终一致性方案性能比XA好很
错误场景一
看起来，好像消息事务就是这么点东西？上游更新完数据，发个消息让下游消费下，下游也更新下自己的数据，这不就完了？
如图所示上游肯定要保证上游数据的处理和消息的发送在一个事务里，常见的伪代码如下
@Transactionalpublicvoidexecute(ActionExecuteParam param){
//更新本地数据库
mapper.update(param);
//发送mq消息通知下游更新数据
mqProducer.sendMsg(msg);}
上面的代码对应到执行流程图，即为如下所示，其中step3是容易被忽略的一步，如果把数据更新和发送mq消息放在一个事务里，那么实际数据的commit操作会在整个方法结束后(也就是消息完成后)进行，假如此时数据库操作出现报错、超时，那么消息已经发出去了，下游数据已经更新，但是上游数据却没有更新，出现了不一致
错误场景二
那么不加事务呢，行不行？如图所示
此时假设step1数据更新完成后，step2进行消息发送的时候，失败了，或者超时异常了，那么step1的数据不会进行回滚(数据已经commit)，此时下游数据未更新，一样出现了不一致的情况
错误场景三
先发消息，再更新数据库行不行？
这种Case就更明显了，如果消息发送成功了，但是这时候系统重启、数据库超时，都有可能导致消息发送成功(下游数据随之更新)，但是上游数据未更新，同样会出现数据不一致
所以关键点是什么？只要上游执行的数据变更操作和发送消息不是一个原子操作，即不在一个事务中完成，那么，无论先后顺序如何，如何操作，都会出现数据不一致性问题
解决方案对比
用表格的形式总结下上面介绍的几种分布式事务解决方案优缺点
事务方案 |
优点 |
缺点 |
2PC(XA事务) |
实现简单 |
1、需要数据库(一般是XA支持) 2、锁粒度大，性能差 |
2PC(Seata AT模式) |
实现简单，业务侵入极低 |
需要引入、部署单独Seata服务，维护成本高 |
TCC |
锁粒度小，性能好 |
需要侵入业务，实现较为复杂，复杂业务实现幂等有难度 |
消息事务 |
业务侵入小，无需编写业务回滚补偿逻辑 |
事务消息实现难度大，强依赖第三方中间件可靠性 |
考虑到消息中间件是平时开发中必不可少的中间件，同时大部分业务场景下并不要求分布式事务的强一致性，因此下面重点介绍基于消息中间件如何实现分布式事务的最终一致性
最终一致性-本地消息表
本地消息表的设计核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息发送日志(记录)可以存储到本地文本、数据库，再通过定时器自动或人工发起重试
即保证业务数据更新成功的同时，一定会有一条对应的消息记录(消息发送状态为待发送)在数据库中，然后上游所在系统单独启动一个定时器去扫描该消息表，并将状态为待发送的消息，投递到消息服务器中，失败重试，直到消息发送成功，那么就能解决数据更新和消息发送的原子性问题
整体流程图如下
如果开发中使用的消息中间件并不支持事务消息的功能，那么本地消息表是一种不错的最终一致性解决方案，那么缺点又是什么？显而易见
业务方需要单独设计消息表，及定时发送消息的定时器，增加了与业务无关的开发负担
最终一致性-RocketMq事务消息
RocketMq 4.3版本中开源了事务消息，开发者可以借此来实现简单的最终一致性。介绍事务消息之前，先抛出两个核心概念：两阶段提交、事务状态定时回查。
两阶段提交
关于两阶段提交的基本概念，贴上一张图来简单说明
因为消息发送是一个远程调用，由于网络的不稳定，无法和本地事务的执行处于一个原子操作中，针对这个缺点，RocketMQ基于两阶段提交协议做了如下改动
l 第一阶段：生产者向MQ服务器发送事务消息(prepare半消息)，服务端确认后回调通知生产者执行本地事务(此时消息为Prepare消息，存储于RMQ_SYS_TRANS_HALF_TOPIC队列中，不会被消费者消费)
l 第二阶段：生产者执行完本地事务后(业务执行完成，同时将消息唯一标记，如transactionId与该业务执行记录同时入库，方便事务回查)，根据本地事务执行结果，返回Commit/Rollback/Unknow状态码
1、服务端若收到Commit状态码，则将prepare消息变为提交(正常消息，可被消费者消费)
2、收到Rollback则对消息进行回滚(丢弃消息)
3、若状态为Unknow，则等待MQ服务端定时发起消息状态回查，超过一定重试次数或者超时，消息会被丢弃
引用一张流程图来说明消息事务的两阶段提交
其中prepare半消息是事务消息的核心，正常情况下生产者投递到Broker的消息(除了延迟消息)，会立马被消费者消息，而事务消息中，需要等待生产者执行完本地事务后，才真正对半消息进行投递，这也就意味着，发送到Broker端的prepare半消息是不会被消费者立马消费到的，为什么呢？
事务消息在Broker端进行存储落盘到CommitLog的时候，会有如下2点特殊处理
修改消息topic为RMQ_SYS_TRANS_HALF_TOPIC，并备份消息原有topic，供后续commit消息时还原消息topic使用
修改消息queueId为0，并备份消息原有queueId，供后续commit消息时还原消息queueId使用
修改完topic和queueId后，事务消息也会像普通消息一样存储在commitLog中
看到这，是不是就明白，为什么prepare消息在发送后不会被立马消费？因为消息topic被修改了
事务状态定时回查
在第二阶段中，生产者在本地事务执行完成后，需要向MQ服务器返回响应状态码，发送状态码的过程也是通过Netty发送网络请求，假设由于网络原因发送失败怎么办？本地事务已经提交/回滚了，但是Commit/Rollback状态码却没发出去，那么MQ服务器上这条prepare消息状态岂不是无法被投递/回滚
因此，MQ服务端会定时扫描存储于RMQ_SYS_TRANS_HALF_TOPIC中的消息，若消息未被处理，则向消费发送者发起回调检查，检查消息对应本地事务执行状态。从而保证消息事务状态最终能和本地事务的状态一致。上图中的4、5、6就是MQ服务端定时回查步骤。
事务消息核心
RocketMq通过引入prepare半消息机制、事务消息回查机制，保证生产者消息的发送与本地事务的执行的原子性，将一个分布式大事务拆分成小事务，减少了系统间的交互。同时通过MQ 的高可用特性(不丢失)，及At-Least-Once 特性确保正确投递的事务消息会在下游一定被消费，从而保证数据的最终一致性。
最后
分布式事务作为平时开发中不可避免的一个技术难点，我们有必要了解其常见的解决方案。又因为消息中间件是开发中不可或缺的一个中间件，通过消息中间件来实现最终一致性是一种成本较低的可靠方案，希望本文介绍的基于消息中间件实现的最终一致性方案原理，对大家平时开发会有所帮助。至于具体的事务消息使用例子，大家可以参考RocketMq官网，由于篇幅原因，这里不再过多介绍。
同时，阿里开源的Seata，包含了上述常见的几种分布式解决方案，如TCC、XA、AT(一种零侵入、业务层面实现补偿、回滚的方案)、Saga(适用于长事务的最终一致性方案)，具有较高的学习价值，有兴趣的同学可以看看其实现原理。
参考资料
http://seata.io/zh-cn/index.html
https://github.com/apache/rocketmq
https://github.com/changmingxie/tcc-transaction
招聘时间：
普惠公众平台、carbo团队持续招人，有兴趣的可以投递简历到：[email protected]
职位描述
1、负责服务管理方向流程编排服务、任务平台的开发与维护。
2、参与项目的系统分析，设计工作，承担核心功能，公共核心架构模块的代码编写。
3、解决各种疑难杂症，系统优化，并且完成产品、平台和组件的沉淀。
4、负责团队稳定性建设工作。
任职要求
1、本科以上学历，计算机软件专业，3 年以上 JAVA 开发经验。
2、JAVA 基础扎实，熟悉 io/nio，多线程等基础知识，熟悉分布式，缓存，消息队列等主流技术。熟悉 spring 、mybatis 等主流框架，熟悉常用的设计模式。
3、具备较强的领域建模能力和业务 sense。
4、具备较强的抗压能力和良好的沟通技巧，优秀的团队合作精神，善于学习，深度思考。