分布式事务解决方案—独立消息服务

        什么叫做独立消息服务?独立消息服务是指:在分布式架构系统当中各个子系统之间相互调用而产生的事物问题的一种解决方案,它提供相应接口服务api供消息生产方,跟消息消费方使用,从而尽可能的达到事物强一致性保证,下面我们将介绍独立消息服务的实现!

        举一个用户下单支付的例子,我们有一个支付网关系统,在接收到第三方回调通知成功的情况下,我们订单系统需要update订单表为已支付,并insert支付流水,在会员账户系统,我们需要往会员账户加余额,记录账户流水等等...

首先,介绍一下独立消息服务由几个子系统组成:

        1、消息服务子系统:主要提供以下作用

                a、用于存储预发送消息

                b、确认并发送消息

                c、查询状态确认超时的消息

                d、确认消息已被成功消费

                e、查询消息确认超时的消息

                f、删除本地消息(已完成)

        2、MQ实时消息服务子系统:mq消息队列

        3、消息状态确认子系统:用于轮询 or 定时任务查询生产方消息投递异常的记录,进行重新投递。

        4、消息恢复子系统:用于轮询 or 定时任务查询 消费端消费失败的异常日志记录,进行消费恢复。

下面介绍正向流程:

          第一步:用户调用网关系统,通过网关系统通过订单系统确认并创建一条待支付的订单,

          第二步:用户微信扫码完成支付,

          第二步:网关系统接收到微信回调通知,调用实时消息服务(mq)投递一条订单队列消息。

          第三步:订单系统监听到实时消息服务mq,调用消息服务子系统 保存一条预发送的消息(更新账户)到消息服务子系统的DB存储。

        第四步:消息服务子系统保存订单系统发来了的预发送消息存到本地DB,并返回存储的结果。

          第五步:订单系统得到消息服务子系统本地存储成功之后,订单系统开始执行本地事物(更新订单状态、并insert支付流水记录),并再次调用消息服务子系统告知订单处理成功的结果,

          第六步:消息服务子系统得到订单处理完成的结果之后,会更新刚才存在本地的那条预发送的消息(更新账户)的状态,改为可发送。并通过调用实时消息服务(mq)投递一条更新会员账户的消息队列。

            第七步:会员系统监听到队列当中的一条更新账户的消息之后,会执行本地更新账户,并将队列中的更新账户消息删除掉,再调用消息服务子系统,确认已消费,并删除这条已被消费的消息记录。

  异常流程:

            1、在第三步中,我调用消息服务子系统 保存一条预发送的消息(更新账户)到消息服务子系统的DB存储的接口当中,如果网络终端导致接口调用失败,或者调用成功但一直得不到消息服务子系统的一个存储结果?

            答:调用失败/收不到反馈结果,本地事物也不会处理。

            2、在第五步中,如果订单系统收到消息服务子系统的预发送消息DB存储成功结果,然后进行本地订单处理的事物也成功/失败,但是由于网络原因,再次调用消息服务子系统告知订单处理成功的结果的这个动作失败,下面流程怎么走?

            答:消息状态确认子系统就是来解决这种异常,它会去轮询消息日志表,根据规则找出预发送状态的消息记录,然后去调用订单系统确认是否已经订单处理完成,如果订单处理失败,则调用消息服务子系统将这条消息记录删除掉,如果订单处理是完成的,则调用正向流程的第六步。

            3、在第六步当中,调用实时消息服务(mq)投递一条更新会员账户的消息队列失败,怎么处理?

            答:消息恢复子系统就是来解决这种异常,它会去轮询消息日志表,根据规则找出消息状态为发送成功,但是还未被消费掉的消息记录,然后重新投递一条消费会员的队列到实时消息服务(mq)中,然后执行正向流程的第七步。

          4、在第七步当中,如果会员账户已经本地事物完成,但是调用消息服务子系统更新状态为已被消费这个动作失败了,该怎么处理?

            答:消息恢复子系统同样会去轮询消息日志表,根据规则找出消息状态为发送成功,但是还未被消费掉的消息记录,然后重新投递一条消费会员的队列到实时消息服务(mq)中,会员系统监听到队列之后,本地需要做一个更新账户幂等性的判断,判断是否已经被处理,如果是处理完成,则再次删除消息队列,并调用消息服务子系统,告知已经被消费。



其它

          可能会有读者问到为什么要单独部署两个定时任务的系统(消息状态确认子系统、消息恢复子系统)? 仔细研究会发现,一个是用来确认生产方的一个流程,一个是用来确认并恢复消费方的一个流程,单独部署可以做到低耦合。

          后面会更新其它关于分布式事物解决的方案,例如 最大努力通知型、TCC阶段提交。

你可能感兴趣的:(分布式事务解决方案—独立消息服务)