多数据源事务

使用 DATASOURCE 模式后，可能一个操作涉及到多个数据源。例如说：创建租户时，即需要操作主库，也需要操作租户库。

考虑到多数据的数据一致性，我们会采用事务的方式，而使用 Spring 事务时，会存在多数据库无法切换的问题。不了解的胖友，可以阅读 《MyBatis Plus 的多数据源 @DS 切换不起作用了，谁的锅 》 (opens new window)文章。

多数据源的事务方案，是一个老生常谈的问题。比较主流的，有如下两种，都是相对重量级的方案：

1. 使用 Atomikos (opens new window)实现 JTA 分布式事务，配置复杂，性能较差。
2. 使用 Seata (opens new window)实现分布式事务，使用简单，性能不错，但是需要额外引入 Seata Server 服务。

#1.1 本地事务

考虑到项目是单体架构，不适合采用重量级的事务，因此采用 dynamic-datasource (opens new window)提供的 “本地事务” 轻量级方案。

它的实现原理是：自定义 @DSTransactional (opens new window)事务注解，替代 Spring @Transactional 事务注解。

• 在逻辑执行成功时，循环提交每个数据源的事务。
• 在逻辑执行失败时，循环回滚每个数据源的事务。

但是它存在一个风险点，如果数据库发生异常（例如说宕机），那么本地事务就可能会存在数据不一致的问题。例如说：

• ① 主库的事务提交
• ② 租户库发生异常，租户的事务提交失败
• 结果：主库的数据已经提交，而租户库的数据没有提交，就会导致数据不一致。

因此，如果你的系统对数据一致性要求很高，那么请使用 Seata 方案。

#1.2 使用示例

在最外层的 Service 方法上，添加 @DSTransactional 注解。例如说，创建租户的 Service 方法：

注意，里面不能嵌套有 Spring 自带的事务，就是上图中【黄圈】的 Service 方法不能使用 Spring @Transactional 注解，否则会导致数据源无法切换。

如果【黄圈】的 Service 自身还需要事务，那么可以使用 @DSTransactional 注解。