首先我先声明一点，本文单纯就是技术探讨，要从实际应用中来说的话，我并不建议这样去玩分布式事务、也不建议这样去玩多数据源，毕竟分布式事务主要还是用在微服务场景下。,好啦，那就不废话了，开整。,首先我们来梳理一下思路。,在上篇文章中，我们是一个微服务，在 A 中分别去调用 B 和 C，当 B 或者 C 有一个执行失败的时候，就去回滚。B 和 C 都是调用远程的服务，所谓的回滚也不是传统意义上的数据库回滚，而是一种“反向补偿”，即利用一条更新 SQL，将已经更新的数据复原。在这个例子中，B 和 C 都是远程服务，操作的也都是不同的数据库，这不就是我们多数据源中的情况么!,在微服务中，一个服务实际上就代表了一个数据源，而在我们多数据源的案例中，一个注解就能标记出来一个数据源，这样一类比，你就会发现利用分布式事务来解决多数据源中的事务问题其实是非常 Easy 的。而且这里还不是微服务项目，只是一个单体项目，更简单!,不过也有一些需要注意的细节。,接下来我们就结合代码来讲讲。,首先多数据源的案例我就不重复写了，我们之前已经写过一个，这里就不再赘述，文章一开头也有相关的链接，还没看过的小伙伴可以先看看。,也可以直接在公众号后台回复 dynamic_datasource 获取相关的案例。,因为上篇文章我主要是和大家分享的 seata 的 AT 模式，所以本文也是一样，就先采用 AT 模式。,小伙伴们知道，在我们的多数据源案例中，我们用到了两个库，test08 和 test09，现在也还是这两个库，但是现在由于我们使用的是 AT 模式，我们需要在这两个库中分别创建 undo log 表，用来记录我们对表的更新操作，当事务提交之后，undo log 表中的数据就会被清除，undo log，undo log 表的脚本如下：,数据库准备好之后，接下来就是准备依赖了，seata 有两个依赖，一个是 seata-all，还有一个微服务版的，咱们这里就直接使用上篇文章中所用到的微服务版的，依赖如下：,配好之后，接下来提供两个配置文件 file.conf 和 regsigry.conf，这两个配置文件和上篇文章中介绍到的一模一样，这里不再赘述。,接下来配置 application.yaml，如下：,大家看下这里的几个配置：,好啦，这个文件就配置好了。,接下来就是数据源问题了，刚刚说了，seata 中会自动代理数据源，用到的代理对象是 DataSourceProxy，而我们在之前自定义的数据源加载中，并没有用到这个 DataSourceProxy 对象所以这里要稍作修改，一共改两个地方，如下：,其实这里的改动就是把之前的 DataSource 用 DataSourceProxy 重新包裹一下，然后将获取到的 DataSourceProxy 存起来。最后再修改一下动态数据源的地方：,Map 中的 value 类型变为 DataSourceProxy，其他都不变。,另外还有一个地方要改造下，就是解析 @DataSource 注解的切面，在之前的解析中，我们是将异常捕获了，现在我们要将之抛出来，如下：,将之抛出来的原因也很简单，因为这是切面方法，所有的 service 层方法都在这里执行，如果将异常捕获了，将来 service 层方法不抛出异常，事务就没法生效了。,好了，现在准备工作就算是到位了。,接下来我们写一个简单的多数据源事务的案例，首先我们来创建一个 MasterService，专门用来操作 master 数据源：,mapper 就不用看了吧，就是普通的添加，大家可以在文末下载本文案例案例。,再来一个 SlaveService，用来操作 slave 数据源：,slave 数据源的方法中有一个异常。,最后，我们在 UserService 中分别调用这两个方法：,注意，test 方法上有一个全局事务注解。,好啦，齐活!现在我们去执行这个 test 方法，由于 slaveService#addAccount 中的方法会抛出异常，所以会导致整个事务回滚，最终的结果就是 master 中也没有添加进数据。,好啦，结合上一篇文章，相信大家应该能够熟练的使用 seata 分布式事务中的 at 模式了吧!
© 版权声明
文章版权归作者所有，未经允许请勿转载。
">