我说分布式事务之消息最终一致性事务(一):原理及实现

2019/1/16 posted in  DTx
SnoWalker  程序猿DD  2019-01-09

原文地址 https://mp.weixin.qq.com/s/gL3LSkxzZ7I97zXvPs6r6Q

在之前的文章中,我们已经学习总结了分布式事务的两种解决方案。

本文我们将学习到另一种常见的柔性事务解决方案:消息一致性事务方案。

对于 TCC 型事务,跨系统的调用均是基于服务间的直接调用,即很大程度上是同步调用。基于 TCC 方案能够保证主子事务同时成功,同时失败。

但实际开发中,由于多方面的考虑,我们会将服务拆分为异步方式,一般是基于 MQ 进行服务间的解耦,服务发起方执行完本地业务操作后发送一条消息给到消息中间件(比如:RocketMQ、RabbitMQ、Kafka、ActiveMQ 等),被动方服务从 MQ 中消费该消息并进行业务处理,从而形成业务上的闭环。

这种场景下,我们还是希望异步的多个业务操作同时成功,同时失败,基于 TCC 的同步型事务解决方案就不可行了,这时就需要祭出可靠消息最终一致性方案。

实现可靠消息服务

首先按照惯例我们先看一下该方案的简略的结构图,如下

核心流程 1:上游投递消息

基于上图,我们分析一下如果要实现一个可靠消息一致性的服务,需要实现哪些功能,要走哪些流程。

调用开始,业务主动方(之后称为主动方)预先发送一条消息到消息服务(图中中间的部分)中,消息中包含后续的业务操作所必须的业务参数,消息服务接收到该消息后存储消息到消息存储中,并设置消息状态为 “待确认”

如果消息存储失败则直接返回消息持久化失败,本次业务操作结束。

当主动方接收到消息存储结果后,开始执行本地的业务操作,根据本地事务提交的结果,调用消息服务的接口。这里分为两种状态:

  1. 如果本地事务执行成功,就调用消息服务确认消息状态,更新为 待发送

  2. 如果本地事务执行失败,就调用消息服务删除消息(一般是逻辑删除,更新消息状态为 已回滚

当状态为第 1 种,消息服务就将该消息发送到 MQ 中,并更新消息状态为 “已发送”

注意:对于消息状态的更新和投递消息到 MQ 中间件的操作应在同一个方法中,并开启本地事务。为什么要这么做呢?

因为我们的目的是:保证消息发送和本地事务同时成功同时失败。

这里还是有两种情况:

  1. 如果更新消息状态失败,则应当抛出异常回滚事务,不投递消息到 MQ 中。

  2. 如果投递 MQ 失败,(需要捕获异常),需要主动抛出异常触发本地事务回滚。

  3. 1.2 要同时成功同时失败

当状态是第 2 种,即本地事务执行失败

业务主动方需要调用可靠消息事务的删除消息操作,消息服务从消息持久化存储中删除该消息(设置消息状态为已回滚

核心流程 2:被动方应用接收消息

被动方服务订阅主题后只需要等待 MQ 投递消息即可。

当消息投递,被动方服务消费该消息并执行本地业务操作,当本地业务执行成功,被动方服务调用消息服务,返回本地业务执行成功。

可靠消息服务根据业务唯一参数(订单号结合消息 id)设置消息状态为 “已完成”

整个过程中,作为被动方服务需要尽最大努力将业务向最终状态推进,最终成功或者失败并通知消息服务置消息状态为完成的终态。

1. 如何保证消息不丢失–即保证消息可靠投递

这里分为多种情况进行讨论。

开始阶段,主动方应用提交 待确认 消息时出错,此时主动方会直接感知到提交失败,业务直接返回失败,不处理后续的流程

主动方应用执行完成本地事务之后,通知可靠消息服务确认或者删除消息阶段,出了问题:例如通知可靠消息服务失败、本地业务执行异常、可靠消息接收到提交请求后投递消息到 MQ 中失败等问题,如何解决?

这类情况即出现业务卡在中间态,其实没关系,因为此时消息持久化状态会一直处于 “待确认” 状态。

对于这种情况,我们只需要在可靠消息服务后台开启一个定时任务,定时扫描 “待确认” 状态的中间状态消息,当消息处于 “待确认” 状态,表明主动方应用已经开始执行本地业务操作,但业务状态未知,因此我们需要对主动方本地业务执行进行回查操作。

这个阶段我们要在主动方应用中暴露一个回调查询接口,可靠消息服务会调用该接口,根据消息中的业务参数回查本地事务执行状态。如果主动方业务返回执行成功,则表明当前消息可以投递,此时可靠消息服务更新消息状态为 “待发送”,同时投递消息到 MQ,并更新消息状态为 已发送

如果,可靠消息服务(通过回查接口)询问主动方业务执行结果,返回执行失败,那么可靠消息服务需要删除该消息(逻辑删除,设置消息状态为已回滚)。

通过上述的流程,我们可以保证可靠消息服务一定会努力尝试完成消息到 MQ 的投递过程,即主动方业务执行与消息发送一定同时成功,同时失败。

2. 如何保证消息不丢失–业务被动方对消息 100% 接收成功

如果消息投递成功,但业务被动方消费消息出现问题,如:消费失败、未收到消息投递(传说中的丢消息)等,该如何处理呢?

因为 “未收到消息投递” 的情况在消息服务高可用的情况下机会不会出现,而消费失败是业务级别的异常,因此我们同样可以采用在可靠消息服务后台起定时任务的方式,检查消息状态。

对长时间处于 “已发送” 未变更状态为 “已完成” 的消息进行重新投递操作,这个扫描的时间我们要根据业务执行时间自行调整,比如:1min。

对这类型消息重新投递到 MQ 之后,MQ 会推送消息给消费方重新进行业务的处理操作。这个过程要在业务层实现消费的 幂等性,保证同一条消息在多次投递之后,只会进行一次完整的业务逻辑处理。关于幂等性,可以参考这篇文章 幂等的实现方案, 后续我也会针对业务层的幂等性写一篇文章出来。

整个流程中,从消息的发送,到消息的消费阶段都能保证消息与本地事务执行状态一致,即使上下游会有短暂的状态不一致,在经过一个处理的时间窗口之后,在全局上,数据能够实现最终一致性。

阶段小结

在上文,我从原理及业务上,分析了如何基于已有的消息中间件实现可靠消息服务,并实现基于可靠消息的最终一致性。

整个流程中,我们能保证:

  1. 业务主动方本地事务提交失败,业务被动方不会收到消息的投递。

  2. 只要业务主动方本地事务执行成功,那么消息服务一定会投递消息给下游的业务被动方,并最终保证业务被动方一定能成功消费该消息(消费成功或失败,即最终一定会有一个最终态)。

这个机制就是基于消息中间件的异步流程中的最终一致性保证方案。

·END·