​

最近，工作中要为现在的老系统做拆分和升级，刚好遇到了分布式事务、幂等控制、异步消息乱序和补偿方案等问题，刚好基于实践结合个人的看法记录一下一些方案和思路。

首先，做系统拆分的时候几乎都会遇到分布式事务的问题，一个仿真的案例如下：

项目初期，由于用户体量不大，订单模块和钱包模块共库共应用（大war包时代），模块调用可以简化为本地事务操作，这样做只要不是程序本身的BUG，基本可以避免数据不一致。后面因为用户体量越发增大，基于容错、性能、功能共享等考虑，把原来的应用拆分为订单微服务和钱包微服务，两个服务之间通过非本地事务操(这里可以是HTTP或者消息队列等)作进行数据同步，这个时候就很有可能由于异常场景出现数据不一致的情况。

以上面的订单微服务请求钱包微服务进行扣款并更新订单状态为扣款这个调用过程为例，假设采用HTTP同步调用，项目如果由经验不足的开发者开发这个逻辑，可能会出现下面的伪代码：

这是一个从肉眼上看起来没有什么问题的解决方法，HTTP调用直接嵌入到事务代码块内部，猜想最初开发者的想法是：HTTP调用失败抛出异常会导致事务回滚，用户重试即可；HTTP调用成功，事务正常提交，业务正常完成。这种做法看似可取，但是带来了极大的隐患，根本原因是：事务中嵌入了RPC调用。假设两种比较常见的情况：

尽管现在有Hystrix等框架可以基于线程池隔离调用或者基于熔断器快速失败，但是这是收效甚微的。因此，个人认为事务中直接RPC调用达到强一致性是完全不可取的，如果使用了这种方式实现"分布式事务"建议整改，否则只能每天祈求下游服务或者网络不出现任何问题。

使用消息队列进行服务之间的调用也是常见的方式之一，但是使用消息队列交互本质是异步的，无法感知下游消息消费方是否正常处理消息。用前一节的例子，假设采用消息队列异步调用，项目如果由经验不足的开发者开发这个逻辑，可能会出现下面的伪代码：

上面的处理方法如果抽象一点表示如下：

这样做，在正常情况下，也就是能够正常调用消息队列中间件推送消息成功的情况下，事务是能够正确提交的。但是存在两个明显的问题：

总的来说：事务中进行异步消息推送是一种并不可靠的实现。

业界目前主流的分布式事务解决方案主要有：多阶段提交方案（2PC、3PC）、补偿事务（TCC）和消息事务（主要是RocketMQ，基本思想也是多阶段提交方案，并且基于中间提供件轮询和重试，其他消息队列中间件并没有实现分布式事务）。这些方案的原理在此处不展开，目前网络中相应资料比较多，小结一下它们的特点：

个人所在的公司的技术栈中没有使用RocketMQ，主要使用RabbitMQ，所以需要针对RabbitMQ做消息事务的适配。目前业务系统中消息异步交互存在三种场景：

最终敲定使用了本地消息表的解决方案，这个方案十分简单：

主要思路是：

伪代码如下：

对于"消息推送实时性高，可以接受丢失"这种情况，实际上不用依赖本地消息表，只要在业务操作事务提交之后组装和推送消息即可，这种情况会存在因为消息队列中间件不可用或者本地应用宕机导致消息丢失的问题(本质是因为数据是内存态，非持久化)，可靠性不高，但是绝大多数情况下是没有问题的。如果使用spring-tx的声明式事务@Transactional或者编程式事务TransactionTemplate，可以使用事务同步器实现嵌入于业务操作事务代码块中的RPC操作延后到事务提交后执行，这样子RPC调用的代码物理位置就可以放置在事务代码块内，例如：

对于使用到本地消息表的场景，需要警惕下面几个问题：

例如本地消息表的设计如下：

个人认为，解决分布式事务的最佳实践就是：

其实，对于一致性和实时性要求相对较高的分布式事务的实现，使用消息队列解耦也有对应的解决方案。

“幂等”（idempotence）这个术语原文来自于HTTP/1.1协议中的定义：

“Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.”

简单来说就是：除了错误或者过期的请求(换言之就是成功的请求)，无论多次调用还是单次调用最终得到的效果是一致的。通俗来说，有一次调用成功，采用相同的请求参数无论调用多少次(重复提交)都应该返回成功。

下游服务对外提供服务接口，必须承诺实现接口的幂等性，这一点在分布式系统中极其重要。

目前实践中对于幂等的处理使用了下面三个方面的控制：

举一个基于消息消费幂等控制的伪代码例子：

补偿方案主要是HTTP同步调用的补偿和异步消息消费失败的补偿。

一般情况下，HTTP同步调用会得到下游系统的同步结果，对结果的处理存在下面几种常见的情况：

首先要有一个简单的认知：短时间内的HTTP重试通常情况下都是无效的。如果是瞬时的网络抖动，短时间内HTTP同步重试是可行的，大部分情况下是下游服务无法响应、下游服务重启中或者复杂的网络情况导致短时间内无法恢复，这个时候做HTTP同步重试调用往往是无效的。

如果面对的场景是内部低并发量的系统之间的进行HTTP交互，可以考虑使用基于指数退避的算法进行重试，举个例子：

如果上面的例子中使用了Hystrix控制超时为1秒包裹着要执行的HTTP命令进行调用，上面的重试过程最大耗时小于20秒，在低并发的内部系统之间的交互是可以接受的。

但是，如果面对的是并发比较高、用户体验优先级比较高的场景，这样做显然是不合理的。为了稳妥起见，可以采取相对传统而有效的方案：HTTP调用的调用瞬时内容保存到一张本地重试表中，这个保存操作绑定在业务处理的事务中，通过定时调度对未调用成功的记录进行重试。这个方案和上文提到保证消息推送成功的方案类似，举一个仿真的例子：

异步消息消费失败的场景发生只能在消息消费方，也就是下游服务。从降低成本的目的上看，消息消费失败的补偿应该由消息处理的一方(消费者)自行承担，画一个系统交互图理解一下：

如果由上游服务进行补偿，存在两个明显的问题：

在最近的一些项目实践中，确定在使用异步消息交互的时候，补偿统一由消息消费方实现。最简单的方式也是使用类似本地消息表的方式，把消费失败的消息入库，并且进行重试，到达重试上限依然失败则进行预警和人工介入即可。简单的流程图如下：

异步消息乱序是使用消息队列进行异步交互场景中需要考虑和解决的问题。下面举一些可能不合乎实际但是能够说明问题的例子。

场景一：上游某个服务向用户服务通过消息队列异步修改用户的性别信息，假设消息简化如下：

用户服务一共使用了10个消费者线程监听user-service.modify.sex.qeue队列。假设上游服务先后向user-service.modify.sex.qeue队列推送下面两条消息：

上面的消息推送和下游处理有比较高几率出现下面的情况：

原本用户ID为1的用户先把性别改为MAN（第一次请求），后来改为WOMAN（第二次请求），最终看到更新后的性别有可能是MAN，这显然是不合理的。这个不是很合理的例子想说明的问题是：通过异步消息交互，下游服务处理消息的时序有可能和上游发送消息的时序并不一致，这样有可能导致业务状态错乱。对于解决这个问题，提供几个可行的思路：

场景二：没有时序要求的异步消息处理，但是要求最终展示的时候是有时序的。这样说可能有点抽象，举个例子：在借呗上借了10000元，还款的时候，用户是分多次还清（例如还款方案一：2000,3000,5000；还款方案二：1000,1000，1000，7000等等），每次还的钱都不一样，最终要求账单展示的时候是按照用户的还款操作顺序。

假设借呗的上游服务和它通过异步消息交互。详细分析一下：这个场景其实对于借呗（主要是考虑收回用户的还款这个目的）来说，对用户还款的顺序并不需要感知，只需要考虑用户是否还清，但是使用异步交互，有可能导致下游无法正确得知用户还款的操作顺序。

解决方案很简单：推送消息的时候附加一个带有增长或者减少趋势的标记位即可，例如使用带有时间戳的标记位或者使用Snowflake算法生成自增趋势的长整型数作为流水号，之后按照流水号排序即可得到消息操作的顺序（这个流水号下游需要保存），但是实际消息处理的时候并不需要感知消息的时序。

个人认为：异步消息结合状态驱动是可以相对完善地解决分布式事务，结合预处理（例如预扣除或者预增长）可以满足比较高一致性和实时性。先引出一个经常用来讨论分布式事务强一致性的转账场景。

解决这个问题如果使用同步调用（其实像TCC、2PC或者3PC等本质都是同步调用），在允许性能损失的情况下是能够达到强一致性。这一节并不讨论同步调用的情况下怎么做，重点研究一下在使用消息队列的情况下，如何从BASE的角度"达到比较高的一致性"。先把这个例子抽象化，假设两个系统的账户表都设计成这样：

两个系统都可以建立一张表结构相似的金额变更流水表，上游系统用于做预扣操作和流水记录，下游系统用于做流水记录，接着我们可以梳理出新的交互时序逻辑如下：

上面的步骤看起来比较多，而且还需要编写对账和重试模块。其实，在上下游系统、消息队列中间件都正常运作的情况下，上面的这套交互方案可承受的并发量远比同步方案高，出现了服务或者消息队列中间件不可用的情况下，由于流水表有未处理的本地记录，在这些问题恢复之后可以重试，可靠性也是比较高的。另外，重试和对账的模块，对于所有涉及金额交易的处理都是必须的，这一点其实选用同步或者异步交互方式并没有关系。

你会发觉，通篇文章有很多方案都是使用了“待处理内容写入本地表 + 事务外实时触发 + 定时调度补偿”这个模式，其实我想表达的就是这个模式是目前分布式解决方案中一个相对通用的模式，可以基本满足分布式事务、同步异步补偿、实时非实时触发等多种复杂场景的处理。这个模式也存在一些明显的问题(如果实践过的话一般会遇到)：

其实，更多的时候需要结合现有的系统或者场景进行分析，通过数据监控和分析进行后续优化。毕竟，架构是迭代出来，而不是设计出来的。