本文内容
- 什么是分布式事务
- 分布式事务中的难点
- 常见的解决方案
- 讲解通过可靠消息来解决分布式事务
什么是分布式事务?
有这样一个需求:
小明有两个账户,分别位于A、B两个数据库中,小明需要将A中的资金转到B中。
我们如何实现?
按照下面的方式实现看看有没有问题。
- 连接数据库A,获取connA连接
- connA打开事务
- A库资金减少100
- 连接库B,获取connB连接
- connB打开事务
- B库资金增加100
- connA.commit()
- connB.commit()
上面操作,正常情况是没有问题。
考虑如下情况:
第7步执行成功之后,网络出问题了,第8步会提交失败,此时的结果是:A库资金减少了100,B库资金却没有增加;这是一个网络问题导致了我们业务失败了,网络因素是程序不可控的一些因素,还有其他的比如运行到7之后,系统突然断电了,也会出现同样的结果。造成了数据错误,对业务影响也是比较大的。
分布式事务可以这么理解:一个业务操作中,会包含很多子业务的,每个子业务都是独立的事务,我们需要考虑的是如何保证这些子业务都成功,或者都失败。
分布式事务中的难点
- 分布式事务中,分支可能是各种各样的,可能存在各种异常情况导致有些成功有些却失败了,这些情况需要我们程序能够处理,保证所有的分支要么都成功、要么都失败,不能出现部分成功而部分失败的情况。
- 分布式事务中,很难保证多个分支同时成功。每个分支可能都是提供远程接口进行调用,之间存在网络故障的问题,前面的分支调用成功了,但是其他分支由于网络等不可控的因素而调用不成功,此时数据是很难做到同时一致性的。
- 实时一致性难以保证。那么我们可以做到最终一致性也是可以的。
什么是最终一致性?
就拿上面的转账来说,A库的资金减少了,由于网络问题,操作B库的connB连接断开了,导致B库资金没有增加;网络问题是可以恢复了,如果网络恢复了,系统能够给B中资金加上,这样最终数据也是正确的;这中间有段时间AB库的资金是不一致的(A库减少了100,B库应该增加100却没有增加,数据是不一致的),但是最终某个时间点数据变为一致了。能够将不一致的时间降到最低是系统需要考虑的问题。
分布式事务中,我们可以接受数据在某个时间段之内不一致,但是数据最终在某个时间点是一致的。
常见解决方案
- 可靠消息模式
- TCC模式实现
分布式事务系列中主要讲这2种方案,这两种方案基本上可以解决大多数常见的分布式事务的问题,所以咱们必须把这两种方式拿下。
下面我们介绍一下使用可靠消息如何实现?
可靠消息模式实现转账操作
两个微服务
服务A:用于操作A库中的账户
服务B:用于操作B库中的账户
两个服务都是链接独立的数据库,依靠数据库提供的功能,能够保证各自的事务。
对于用户来说过程如下:
- 调用服务A,扣款100
- 发送扣款成功的消息到消息服务
- 返回用户转账已受理
接着
- 服务B,拉取到转账消息
- B库中给账户+100
- 调用消息服务将消息删除
- 服务B消费的过程中,比如出现网络、机器重启等原因,导致消费失败,等机器恢复之后,可以再次消费这条消息,重试多次最终会成功
上面整个转账过程中有几点我们需要考虑一下:
- 如何确保A服务中扣款成功之后,消息一定能够发送成功;如果消息发送失败而丢失了,后面的业务将没法进行。这块涉及如何发送可靠消息,之前消息系列的文章有介绍,大家可以看一下:
- 我们的服务一般都是集群的方式,消息消费的时候,可能会出现一条消息并发消费的情况,并发情况发生的时候,如何确保消费只能够被消费成功一次。如果一条转账消息被成功消费两次,最终B账户中将增加200,导致业务出错。这块可以参考如何保证消息消费的幂等性,这块之前也有讲过,大家也可以看一下:
依靠消息模式实现分布式事物,比较适合消费者一定会处理成功的场景。比如用户注册发送邮件、发送短信、送积分等。
总结
- 本文主要介绍了什么是分布式事务、其中的一些难点
- 常见的使用最多的解决方案:异步消息处理分布式事物、tcc模式
- tcc模式我们在后面的文章中介绍,目前在我们自己的系统中实现了通用的tcc,已经上线运行,运行也比较稳定
- 对分布式事务有兴趣、或有疑问的,可以加我微信itsoku交流
- 请关注公众号javacode2018,更多好文及时推送给您