分布式事务之可靠消息设计要点汇总

Posted 2021-04-23 Java充电社

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了分布式事务之可靠消息设计要点汇总相关的知识，希望对你有一定的参考价值。

本文介绍分布式事务的另外一种解决方案：可靠消息最终一致性。

1、什么是可靠消息最终一致性？

可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。

这里面有 2 个重点：

电商中有这样的一个场景：商品下单之后，需给用户送积分，订单表和积分表分别在不同的 db 中，涉及到分布式事务的问题。

我们通过可靠消息来解决这个问题：

我们主要讨论一下，商品下单及投递消息到 mq 的操作，如何实现？每种方式优缺点？

这种方式是将发送消息放在了事务提交之前。

下面我们换种方式，我们将发送消息放到事务之后进行。

step4 发生异常，其他 step 成功：导致商品下单成功，投递消息失败，用户未增加积分

上面两种是比较常见的做法，也是最容易出错的。

这种方式借助了数据库的事务，业务和消息记录作为了一个原子操作，业务成功之后，消息日志必定是存在的。解决了前两种方式遇到的问题。如果我们的业务系统比较单一，可以采用这种方式。

对于微服务化的情况，上面这种方式不是太好，每个服务都需要上面的操作；也不利于扩展。

增加一个消息服务及消息库，负责消息的落库、将消息发送投递到 mq。

能想到上面这种方式，已经算是有很大进步了，我们继续分析一下可能存在的问题：

系统中增加了一个消息服务，商品下单操作依赖于该服务，业务对该服务依赖性比较高，当消息服务不可用时，整个业务将不可用。
若 step6 失败，消息将处于待发送状态，此时业务方需要提供一个回查接口（通过 bus_id 查询）,验证业务是否执行成功；消息服务需新增一个定时任务，对于状态为待发送状态的消息做补偿处理，检查一下业务是否处理成功；从而确定消息是投递还是取消发送
step4 依赖于消息服务，如果消息服务性能不佳，会导致当前业务的事务提交时间延长，容易产生死锁，并导致并发性能降低。我们通常是比较忌讳在事务中做远程调用处理的，远程调用的性能和时间往往不可控，会导致当前事务变为一个大事务，从而引发其他故障。

在以上方式中，我们继续改进，进而出现了更好的一种方式：

step1：生成一个全局唯一业务消息 id（bus_msg_id)，调用消息服务，携带 bus_msg_id，将消息先落地入库，此时消息的状态为待发送状态，返回消息 id（msg_id）
step2：开启本地事务
step3：生成购物订单
step4：当前事务库插入一条日志（将 step3 中的业务和 bus_msg_id 关联起来）
step5：提交本地事务
step6：分 2 种情况：如果上面都成功，调用消息服务，将消息投递到 mq 中；如果上面有失败的情况，则调用消息服务取消消息的发送