基于消息中间件的分布式事务

时间: 2019-02-02阅读: 120标签: 分布式

前言

此文来源于我的博客网站:http://51think.net

关于分布式事务的实现,网上有很多解说,当然这也是面试官的常备面试题。很多朋友在工作中很少接触到分布式事务,认为这个玩意交互太多,没必要。其实我也是这么想的,想要完成一个完整的分布式事务链路,通信开销实在太多。而现如今,微服务架构在行业内大行其道,恨不得所有模块都用上微服务来管理,而不知道自己已经慢慢失去了对软件控制的能力,从数据层面上来说,我们降低了对数据一致性控制的能力。既然市场上很流行,我们还是需要了解一下的,借此,本文介绍一下基于消息中间件的分布式事务的原理。


一、核心思想

了解分布式事务,我们需要抓住几个重点。我总结了一下,可以称之为232法则,即两个角色,三个阶段,两个结果。两个角色是指系统中要存在协调者角色和参与者角色,本文中消息服务器充当协调者,客户端和服务端充当参与者;三个阶段是指分布式事务可以分为预提交阶段,提交阶段,撤销阶段。两个结果是指,参与者中的执行操作要么全部执行,要么全部失败,不能出现部分成功部分失败的情况。

基于消息服务器的分布式事务,我们需要将事务划分成两个部分,一个是客户端与消息服务器交互的提交部分,一个是服务端与消息服务器交互的消费部分。我们需要保证两点: 
1、确保客户端处理完业务后一定能成功发送消息。 
2、确保服务端一定能够消费掉此消息。 
剩下的就看我们如何在交互上完成这两个目标。


二、客户端提交


客户端提交大概可以分为如下几个步骤: 
1、A系统预提交消息。 
2、消息服务器保存消息,但是处于未提交状态,不能被B系统消费。 
3、消息服务器给予响应。 
4、A系统处理本地业务。 
5、A系统提交事务。

可能会存在的问题: 
1、第1、2、3步其中之一出现问题,则不会执行A系统本地业务,故不会出现问题。 
2、第4步如果执行失败,则直接回滚此操作。 
3、第5步如果执行失败,则消息服务器不知道A系统的执行状态,这个场景下,我们需要在A系统中开放查询接口,供消息服务器反查。如果查询到A系统的状态是已提交,则消息服务器将同步此状态,使得B系统可以正常消费。如果查询到A系统的状态是已回滚,则消息服务器将这个消息删除。

通过以上操作,我们可以保证A系统的业务执行状态和消息的发送状态是一致的。可能有的同学会有所疑问,上述操作有点繁琐,为何不先执行A业务,再提交消息和事务呢?如下图:

仔细思考一下,这样做是存在问题的。A业务处理成功后,消息预提交阶段可能会失败,比如网络原因或者消息服务器自身内部原因,导致这个消息没有持久化。正因为没有持久化,消息服务器不会进行反查,这会导致A业务处理状态和消息服务器的消息状态不一致,更别谈被B系统消费了。


三、服务端消费


服务端消费分为如下几个步骤: 
1、B系统消费消息。 
2、B系统处理本地业务。 
3、消费响应,此时消息服务器可以将消息删除。

在服务端消费部分,我们要保证消费一定要成功。可能会出现以下情况: 
1、B系统无法接受到消息。 
2、B系统处理本地业务失败,无法给予消息服务器响应。 
这两种场景下,我们需要对消息服务器提出要求,如果再超时时间范围内,仍然获取不到B系统的消费响应,则进行超时重发,当然B系统需要保证幂等性。但是超时重发需要注意一下,因为有可能B系统一直执行失败,不能陷入无限的重发操作中。这时,我们需要在消息服务器层对消息属性进行定义,即设置一个超时重发的次数,超过了就不在重发,避免资源浪费。消息重发次数如果达到了阈值,说明我们的系统可能出现了问题,这种场景要能够被监控平台捕捉,以便及早的进行人工干预。


四、差错处理

设计再严格的系统,我们都不能掉以轻心。理想状态下,AB系统是可以保证数据的一致性,但不排除有其他意外情况。我们可以根据业务规则,对AB系统的数据进行监控,如果出现不一致的情况,要及早的进行人工干预。


内容以共享、参考为目的,请勿用于商业用途。其版权归原作者所有,如有侵权,请与小编联系,情况属实将予以删除!

广告赞助文章投稿关于web前端网站点搜索站长推荐网站地图站长QQ:522607023

小程序专栏: 土味情话心理测试脑筋急转弯幽默笑话段子句子语录成语大全