用MQ消息实现分布式事务关键点

Posted 2021-04-25 架构师技术

        在微服务架构中，分布式事务是个关键问题，解决办法很多，常用的一种解决方案是利用消息中间件MQ实现数据最终一致性，但在利用消息中间件时如何保证消息必达？

要想消息必达，必须保证：

（1）消息接收落地

（2）消息超时、重发及确认

一，MQ消息可靠投递核心流程（“摘自架构师之路”）

MQ既然将消息投递拆成了上下半场，为了保证消息的可靠投递，上下半场都必须尽量保证消息必达。

MQ消息投递上半场，MQ-client-sender到MQ-server流程见上图1-3：

（1）MQ-client将消息发送给MQ-server（此时业务方调用的是API：SendMsg）

（2）MQ-server将消息落地，落地后即为发送成功

（3）MQ-server将应答发送给MQ-client（此时回调业务方是API：SendCallback）

 

MQ消息投递下半场，MQ-server到MQ-client-receiver流程见上图4-6：

（1）MQ-server将消息发送给MQ-client（此时回调业务方是API：RecvCallback）

（2）MQ-client回复应答给MQ-server（此时业务方主动调用API：SendAck）

（3）MQ-server收到ack，将之前已经落地的消息删除，完成消息的可靠投递

 

如果消息丢了怎么办？

MQ消息投递的上下半场，都可以出现消息丢失，为了降低消息丢失的概率，MQ需要进行超时和重传。

 

上半场的超时与重传

MQ上半场的1或者2或者3如果丢失或者超时，MQ-client-sender内的timer会重发消息，直到期望收到3，如果重传N次后还未收到，则SendCallback回调发送失败，需要注意的是，这个过程中MQ-server可能会收到同一条消息的多次重发。

 

下半场的超时与重传

MQ下半场的4或者5或者6如果丢失或者超时，MQ-server内的timer会重发消息，直到收到5并且成功执行6，这个过程可能会重发很多次消息，一般采用指数退避的策略，先隔x秒重发，2x秒重发，4x秒重发，以此类推，需要注意的是，这个过程中MQ-client-receiver也可能会收到同一条消息的多次重发。

 

MQ-client与MQ-server如何进行消息去重，如何进行架构幂等性设计，下一次撰文另述，此处暂且认为为了保证消息必达，可能收到重复的消息。

二，可靠消息系统设计（引用https://my.oschina.net/xliangbo/blog/1545040）

如上图 

开始执行 比如：

try{

     if(prepare()) { //预发送阶段

         doService(); //执行业务逻辑

         updateMsgStatus();//更新消息为确认状态

     }      

}

 

1 预发送消息，try阶段，如果预发送消息失败了，业务还未执行，所以 系统A，B还是一致性的 不需要处理

这一点容易理解

2 预发送消息成功了，开始执行业务逻辑。执行成功 更新预发送消息转态为确认发送。如果 此时 业务逻辑执行失败了，那预发送消息就不会跟新状态，此时消息确认系统就开启工作，到业务系统1上回查此消息状态，此时发现业务执行失败了，就更新预发送状态至失败状态。

3 如果此时 业务执行成功了消息也被更新成确认发送了 那就ok 完美。如果消息更新失败，还是由消息确认系统回查转态 更新此消息被删除状态还是确认发送状态。

4 消息者开始消费

1 比如消费失败了，此时产生不一致， 消息恢复系统检测消息状态，重新发送消息

2 如果执行业务失败了，此消息也就不会被确认了，还是由消息恢复系统检测消息状态，重新发送消息

3 如果ask失败了，还是以上逻辑重新发送

上诉重新发送当然有次数限制，不能一直发送，超过最大次数就要进入死信队列，等待人工干预了

4 ask成功，消息也就成功消费了，完美，解决了消息可靠服务