第7章 分布式系统架构 【补充：可靠消息最终一致性】

本节主要参考：小白不想上班 链接：https://www.jianshu.com/p/0f50adfc9992，有部分补充内容

14.5. 分布式事务解决方案之可靠消息最终一致性

14.5.1 什么是可靠消息最终一致性事务

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

此方案是利用消息中间件完成，如下图：

 

案例：

 

图中订单服务在执行“下单”操作时，需要同时执行“保存订单”与“库存扣减”，并放在同一个事务中。然而，订单有订单数据库，库存有库存数据库，因此需要分布式事务。但订单服务在面对大促这样的高并发场景时，不能接受传统的XA分布式事务。

这时，订单服务将“保存订单”与“发送消息”做到同一事务中。由于将消息发送到消息队列中速度极快，因此就可以获得极大的吞吐量。接着，库存服务再从消息队列中读取消息，完成后续的“库存扣减”操作。这就是“基于消息的分布式事务”。

事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件之间，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事务问题。

因此可靠消息最终一致性方案要解决以下几个问题：

（1）本地事务与消息发送的原子性问题

本地事务与消息发送的原子性问题即：事务发起方在本地事务执行成功后消息必须发出去，否则就丢弃消息。即实现本地事务和消息发送的原子性，要么都成功，要么都失败。本地事务与消息发送的原子性问题是实现可靠消息最终一致性方案的关键问题。

下面这种操作，先发送消息，再操作数据库：

begin transaction；
    //1.发送MQ
    //2.数据库操作
commit transation;

这种情况下无法保证数据库操作与发送消息的一致性，因为可能发送消息成功，数据库操作失败。那么第二种方案，先进行数据库操作，再发送消息：

begin transaction；
    //1.数据库操作
    //2.发送MQ
commit transation;

这种情况下貌似没有问题，如果发送 MQ 消息失败，就会抛出异常，导致数据库事务回滚。但如果是超时异常，数据库回滚，但 MQ 其实已经正常发送了，同样会导致不一致。

（2）事务参与方接收消息的可靠性
事务参与方必须能够从消息队列接收到消息，如果接收消息失败可以重复接收消息

（3）消息重复消费的问题

由于网络延迟的存在，若某一个消费节点超时但是消费成功，此时消息中间件会重复投递此消息，就导致了消息的重复消费。

要解决消息重复消费的问题就要实现事务参与方的方法幂等性。

14.5.2 解决方案

上节讨论了可靠消息最终一致性事务方案需要解决的问题，本节讨论具体的解决方案。

14.5.2.1 基于关消息的分布式事务

所谓“半消息”就是发送方发送给消息队列消息以后，消息处于暂不投递的状态，直到发送方发出“提交消息”，消息队列才投递给消费者。这样，订单服务先发送半消息，但消息队列暂不投递，而是给订单服务一个确认消息。订单服务收到确认消息以后，保存订单，再发送提交信息。消息队列收到确认信息以后再投递，库存服务才能收到这个消息，完成后续的库存扣减。

 

这个方案增加了消息队列投递的确认环节，保证消息有且只有一次投递给消费者，即最终投递的是发送方确认信息的那一个，其他重复的半消息未经确认是不会投递的。但是，这依然存在提交消息丢失的问题。因此，需要发送方具有“消息反查”的接口，如果消息队列发现某个半消息等待时间过长未投递，那么就到发送方反查该业务是否提交。如果提交则开始投递，否则继续等待。目前比较主流的消息队列中，只有RocketMQ具有半消息的能力。

14.5.2.2 本地消息表方案（基于消息表的分布式事务）

 

本方案将分布式事务变为“保存订单”和“保存消息”放在同一事务中。由于消息表与订单表放到了订单数据库中，因此访分布式事务就变成了本地事务。接着，系统再通过一个进程将消息表中的消息，可靠投递到消息队列 ，并最终投递给库存服务中。这样，由于后面的消息投递在事务之外了，因此即能保证了系统性能，又使系统设计得到简化。

但是这个方案不能保证消息的投递不重复，因此需要在库存服务中增加幂等方面的设计。所谓“幂等”设计，就是某个操作无论执行多少次得到的结果都是一样的。这里的幂等设计有以下两个方面的措施：

（1）分布式锁：消息队列对同一个订单发送了多个消息，而库存服务也可能部署多个节点，因此必须要通过分布式锁保障一次只有一个节点在处理这个订单的扣减，其他节点都只能等待。

（2）幂等性写库：保证一个订单只能扣减一次，那么发送的消息应当包含扣减所充对应的订单号，在写库扣减时，应当先检查该订单是否已经执行过扣减，如果没有才能执行扣减，并在另一个表中记录该订单已经扣减，当另一个请求再次对该订单执行库存扣减时，执行将失败，从而保证了库存扣减的幂等性。

（3）最后，如果“库存扣减”失败，又该怎么办呢？不要为小概率事件进行复杂设计，当“库存扣减”失败时，我们应该写日志、找运维，进行人工干预。

本地消息表这个方案最初是 eBay 提出的，此方案的核心是通过本地事务保证数据业务操作和消息的一致性，然后通过定时任务将消息发送至消息中间件，待确认消息发送给消费方成功再将消息删除。

案例二：

下面以注册送积分为例来说明：下例共有两个微服务交互，用户服务和积分服务，用户服务负责添加用户，积分服务负责增加积分。

 

交互流程如下：

（1）用户注册

用户服务在本地事务新增用户和增加 "积分消息日志"。（用户表和消息表通过本地事务保证一致）

begin transaction
    //1.新增用户
    //2.存储积分消息日志
commit transation

这种情况下，本地数据库操作与存储积分消息日志处于同一个事务中，本地数据库操作与记录消息日志操作具备原子性。

（2）定时任务扫描日志

如何保证将消息发送给消息队列呢？

经过第一步消息已经写到消息日志表中，可以启动独立的线程，定时对消息日志表中的消息进行扫描并发送至消息中间件，在消息中间件反馈发送成功后删除该消息日志，否则等待定时任务下一周期重试。
（3）消费消息

如何保证消费者一定能消费到消息呢？

这里可以使用 MQ 的 ack（即消息确认）机制，消费者监听 MQ，如果消费者接收到消息并且业务处理完成后向 MQ 发送 ack（即消息确认），此时说明消费者正常消费消息完成，MQ 将不再向消费者推送消息，否则消费者会不断重试向消费者来发送消息。

积分服务接收到"增加积分"消息，开始增加积分，积分增加成功后向消息中间件回应 ack，否则消息中间件将重复投递此消息。

由于消息会重复投递，积分服务的"增加积分"功能需要实现幂等性。

14.5.3 小结

可靠消息最终一致性就是保证消息从生产方经过消息中间件传递到消费方的一致性：
本地事务与消息发送的原子性问题。
事务参与方接收消息的可靠性。

可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。引入消息机制后，同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响，并实现了两个服务的解耦。