浅谈分布式事务

时间:2017-05-23作者:klpeng分类:系统架构浏览:3266评论:1

分布式事务的概念,就不用多说了,总体来说,分布式事务是大型系统中比较复杂的技术点了,今天简单介绍一下,分布式系统中,事务的实现。


场景以微服务架构下的某购物平台在线下单为例:

在线下单涉及到订单微服务,支付微服务,库存微服务,明显的,三个微服务的库表都是独立的,也不在一台服务器上,要么三个的操作都成功,要么都回滚。

在传统的单应用系统中,这个问题很容易实现,利用关系型数据库的事务start、commit、rollback可以轻松的保证强一致性。然后在分布式下,强一致性,显然是不可能的,

目前主流的做法都是通过消息中间件来实现最终一致性,下面我简单介绍一下原理,主要用到的是MQ和应用本身的事务机制。

浅谈分布式事务

如上图:

1、A系统向消息中间件发送一条预备消息

2、消息中间件保存预备消息并返回成功

3、A执行本地事务

4、A发送提交消息给消息中间件


通过以上4步完成了一个消息事务。对于以上的4个步骤,每个步骤都可能产生错误:

步骤1出错,则整个事务失败,不会执行A的本地操作

步骤2出错,则整个事务失败,不会执行A的本地操作

步骤3出错,这时候需要回滚预备消息,怎么回滚?答案是A系统实现一个消息中间件的回调接口,消息中间件会去不断执行回调接口,检查A事务执行是否执行成功,如果失败则回滚预备消息

步骤4出错,这时候A的本地事务是成功的,那么消息中间件要回滚A吗?答案是不需要,其实通过回调接口,消息中间件能够检查到A执行成功了,这时候其实不需要A发提交消息了,消息中间件可以自己对消息进行提交,从而完成整个消息事务

基于消息中间件的两阶段提交往往用在高并发场景下,将一个分布式事务拆成一个消息事务(A系统的本地操作+发消息)+B系统的本地操作,其中B系统的操作由消息驱动,只要消息事务成功,那么A操作一定成功,消息也一定发出来了,这时候B会收到消息去执行本地操作,如果本地操作失败,消息会重投,直到B操作成功,这样就变相地实现了A与B的分布式事务。原理如下:

浅谈分布式事务

上面的方案A和B并不是严格一致的,而是最终一致的,这里牺牲了一致性,换来了性能的大幅度提升。当然,这种做法也是有风险的,如果B一直执行不成功,那么一致性会被破坏,具体如何应用要根据业务系统的风险承担能力来。


其实分布式事务,本质上是对多个数据库的事务进行统一控制,目前主流的设计思路和解决方案都有各自的优势和劣势,分布式事务一致性一直以来都是一个技术难题,目前没有一种很简单很完美的方案能够应对所有场景。具体还是要开发者根据不同的业务场景去抉择。

打赏
文章版权声明:除非注明,否则均为彭超的博客原创文章,转载或复制请以超链接形式并注明出处。
相关推荐

  • 评论列表:

发表评论:

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

猜你喜欢