本文由 简悦 SimpRead 转码， 原文地址 www.toutiao.com
中间件方案 RocketMq 事务方案 RocketMq 回查回查判断业务是否成功总结前言 在系统变的复杂后，分布式、微服务等架构技术，就要考虑到应用在
欢迎关注头条号：老顾聊技术
精品原创技术分享，知识的组装工
- 前言
- 场景
- 问题
- 消息中间件方案
- RocketMq 事务方案
- RocketMq 回查
- 回查判断业务是否成功
- 总结
在系统变的复杂后，分布式、微服务等架构技术，就要考虑到应用在系统中了。尤其数据量大了后，就需要对数据库进行拆分。
如：注册的用户数据，量大了后，就需要考虑分库分表
一旦数据库进行了分拆，那就出现很多头疼的问题，其中之一就是事务问题。那我们就来看看问题是怎么出现的？
先来上个图
进行数据拆分后，就类似上面的架构，可以看老顾上一篇文章关于女程序员问到这个问题，让我思考了半天，Mysql 的 “三高” 架构
上图中我们就拿用户的数据进行举例，用户量一旦几千万时，就需要进行分库分表；上图就分了 3 个库，每个库都保证了高可用。
这样的架构设计，会遇到事务问题，我们来看看具体的业务场景：
用户 A 转账 100 元给用户 B，这个业务比较简单，我们来分析一下里面具体的步骤：
1、用户 A 的账户先扣除 100 元
2、再把用户 B 的账户加 100 元
逻辑很简单，上伪代码
代码也是比较清晰的，感觉没有什么问题，那我们来分析一下问题在哪？
我们看到在转账业务中，有两步，一个是操作用户 A 扣钱，一个是操作用户 B 加钱
如果在同一个数据库中进行，可以保证这两步操作，要么同时成功，要么同时不成功。这样就保证了转账的数据一致性。
但是如果用户 A 的数据在集群 A 中，用户 B 在集群 B 中呢？因为他们不在同一个事务中；如用户 A 扣款成功，但用户 B 加钱失败了；那就坑了，数据不完整了。
类似这种问题在微服务架构会更多，因为各个服务都是独立的模块，都是远程调用，都没法在同一个事务中，都会遇到事务问题。
那怎么解决？ 网上有一些方案，如：两阶段提交，TCC 等，还有常用就是最终一致性方案。 老顾就给大家介绍一下如何利用消息中间件去解决。那我们就把方案调整一下，加入消息中间件，看看如何优化。
上图就是利用消息中间件的方式，把扣款业务和加钱业务异步化，扣款成功后，发送 “扣款成功消息” 到消息中间件；加钱业务订阅 “扣款成功消息” ，再对用户 B 加钱
系统怎么知道给用户 B 加钱呢？ 是消息体里面包含了源账户和目标账户 ID，以及钱数
这个时候也许小伙伴们会问，应该也有问题吧：
场景一：先扣款后发消息
先扣款再发送消息，万一发送消息失败了，那用户 B 就没法加钱
那把顺序调整一下
场景二：先发消息，后扣款
扣款成功消息发送成功，但用户 A 扣款失败，可加钱业务订阅到了消息，用户 B 加了钱
大家应该发现了问题所在，也就是没法保证扣款和发送消息，同时成功，或同时失败；导致数据不一致。
因为上面的问题，RocketMq 消息中间件把消息分为两个阶段：Prepared 阶段和确认阶段
Prepared 阶段（预备阶段）
该阶段主要发一个消息到 rocketmq，但该消息只储存在 commitlog 中，但 consumeQueue 中不可见，也就是消费端（订阅端）无法看到此消息。
commit/rollback 阶段（确认阶段）
该阶段主要是把 prepared 消息保存到 consumeQueue 中，即让消费端可以看到此消息，也就是可以消费此消息。
我们用图来说明下：
整个流程：
1、在扣款之前，先发送预备消息
2、发送预备消息成功后，执行本地扣款事务
3、扣款成功后，再发送确认消息
4、消息端（加钱业务）可以看到确认消息，消费此消息，进行加钱
确认消息说明
注意：上面的确认消息可以为 commit 消息，可以被订阅者消费；也可以是 Rollback 消息，即执行本地扣款事务失败后，提交 rollback 消息，即删除那个预备消息，订阅者无法消费
我们来分析一下异常场景：
异常 1： 如果发送预备消息失败，下面的流程不会走下去；这个是正常的
异常 2： 如果发送预备消息成功，但执行本地事务失败；这个也没有问题，因为此预备消息不会被消费端订阅到，消费端不会执行业务。
异常 3： 如果发送预备消息成功，执行本地事务成功，但发送确认消息失败；这个就有问题了，因为用户 A 扣款成功了，但加钱业务没有订阅到确认消息，无法加钱。这里出现了数据不一致。
那 RocketMq 是怎么解决的呢？
RocketMq 如何解决上面的问题，核心思路就是【状态回查】 ，也就是 RocketMq 会定时遍历 commitlog 中的预备消息。
因为预备消息最终肯定会变为 commit 消息或 Rollback 消息，所以遍历预备消息去回查本地业务的执行状态，如果发现本地业务没有执行成功就 rollBack，如果执行成功就发送 commit 消息。
上面的异常 3，发送预备消息成功，本地扣款事务成功，但发送确认消息失败；
因为 RocketMq 会进行回查预备消息，在回查后发现业务已经扣款成功了，就补发 “发送 commit 确认消息” ；这样加钱业务就可以订阅此消息了。
这个思路其实把异常 2 也解决了，因为本地事务没有执行成功，RocketMQ 回查业务，发现没有执行成功，就会发送 RollBack 确认消息，把消息进行删除。
小伙伴们在回查业务中，如何判断本地事务是否执行成功？
如果本地事务执行了很多张表，那是不是我们要把那些表都要进行判断是否执行成功呢？这样是不是太麻烦了，而且和业务很耦合。
有没有更好的方式呢？
就是设计一张 Transaction 表，将业务表和 Transaction 绑定在同一个本地事务中，如果扣款本地事务成功时，Transaction 中应当已经记录该 TransactionId 的状态为「已完成」。当 RocketMq 回查时，只需要检查对应的 TransactionId 的状态是否是「已完成」就好，而不用关心具体的业务数据。
上面就是老顾介绍的 RockMq 的分布式方案，至于消费端（加钱业务）需要考虑幂等设计，之前老顾的文章【何为幂等？如何设计？】有介绍，小伙伴自行查阅。
还有一点，留一个问题，如果我们不用 RockMq 消息中间件，而是用普通的消息中间件如：RabbitMq，这怎么去设计呢？
好了，今天就介绍到这里，谢谢！！！
-End-
推荐阅读
1、女程序员问到这个问题，让我思考了半天，Mysql 的 “三高” 架构
2、大厂二面：CAP 原则为什么只能满足其中两项？而不能同时满足
5、你了解如何利用 token 方式实现分布式 Session 吗？
6、Mysql 索引结构演变，为什么最终会是那个结构呢？让你一看就懂
9、面试题：Thread 的 start 和 run 的区别
15、分享一线互联网大厂分布式唯一 ID 设计 之 snowflake 方案
19、如何永不迁移数据和避免热点? 根据服务器指标分配数据量 (揭秘篇)
20、你知道怎么分库分表吗？如何做到永不迁移数据和避免热点吗？
22、你知道如何更新缓存吗？如何保证缓存和数据库双写一致性？
23、你知道怎么解决 DB 读写分离，导致数据不一致问题吗？