java跨用问题怎么解决_分布式事务系列 - 解决跨库转账问题

本文内容

什么是分布式事务

分布式事务中的难点

常见的解决方案

讲解通过可靠消息来解决分布式事务

什么是分布式事务？

有这样一个需求：

小明有两个账户，分别位于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服务中扣款成功之后，消息一定能够发送成功；如果消息发送失败而丢失了，后面的业务将没法进行。这块涉及如何发送可靠消息，之前消息系列的文章有介绍，大家可以看一下：聊聊业务系统中投递消息到mq的几种方式

我们的服务一般都是集群的方式，消息消费的时候，可能会出现一条消息并发消费的情况，并发情况发生的时候，如何确保消费只能够被消费成功一次。如果一条转账消息被成功消费两次，最终B账户中将增加200，导致业务出错。这块可以参考如何保证消息消费的幂等性，这块之前也有讲过，大家也可以看一下：探讨一下实现幂等性的几种方式

依靠消息模式实现分布式事物，比较适合消费者一定会处理成功的场景。比如用户注册发送邮件、发送短信、送积分等。

总结

本文主要介绍了什么是分布式事务、其中的一些难点

常见的使用最多的解决方案：异步消息处理分布式事物、tcc模式

tcc模式我们在后面的文章中介绍，目前在我们自己的系统中实现了通用的tcc，已经上线运行，运行也比较稳定

对分布式事务有兴趣、或有疑问的，可以加我微信itsoku交流

可以关注公众号：路人甲Java，获取年薪50万课程，获取最新文章。