Spring Boot 多数据源事务陷阱深度解析从踩坑到完美解决 目录一、问题背景与核心痛点二、根因深度剖析三、完美解决方案四、编程式 vs 声明式事务五、ThreadLocal 的核心作用六、跨库回滚方案对比七、最佳实践总结一、问题背景与核心痛点1.1 业务场景预警盒子系统需要管理设备信息涉及两个数据库主库warning-master设备信息、设备区域关系等业务数据气象库basemete气象站点信息等基础数据**核心需求**编辑设备信息时需要同时操作两个库。1.2 问题代码ServicepublicclassDeviceInfoServiceImpl{ResourceprivateDeviceStationConfigServicedeviceStationConfigService;OverrideTransactional(rollbackForException.class)// ⚠️ 问题根源publicvoideditDeviceInfo(DeviceInfoModelidModel,...){// 1. 查询旧数据主库✅DeviceInfoModeloldDataselectById(idModel.getId());// 2. 更新设备信息主库✅updateById(idModel);// 3. 更新设备站点绑定主库 气象库❌ 报错deviceStationConfigService.deviceBindStation(deviceStationConfigModel);}}ServicepublicclassDeviceStationConfigServiceImpl{ResourceprivateStationServicestationService;// 操作气象库OverridepublicvoiddeviceBindStation(DeviceStationConfigModelmodel){// ❌ 这里应该查询气象库但实际查询了主库ListStationModelliststationService.list(wrapper);// 错误Table warning_master.station doesnt exist}}1.3 错误现象Error:Tablewarning_master.station doesnt exist明明 StationMapper 标注了 DS(“basemete”)为什么还会查主库二、根因深度剖析2.1 调用链分析editDeviceInfo(Transactional)└─deviceBindStation()└─stationService.list(DS(basemete))2.2 核心原因Spring 事务基于 AOP 代理数据源切换优先级低于事务管理器sequenceDiagram participant Client as 调用方 participant TX as editDeviceInfobr/事务A(主库) participant DS as DynamicDataSource participant DB1 as 主库 participant DB2 as 气象库 Client-TX: 调用 editDeviceInfo activate TX Note over TX,DB1: 开启事务Abr/绑定主库连接 TX-DS: 获取数据源 DS-DB1: 返回主库连接br/(事务已绑定) TX-TX: 调用 deviceBindStation TX-DS: 尝试切换 basemete DS-DB1: ❌ 仍返回主库连接br/(事务未释放) TX-DB1: SELECT * FROM station DB1--TX: Table doesnt exist! deactivate TX2.3 两个致命陷阱陷阱一事务传播导致连接复用Transactional// 外层事务绑定主库连接publicvoidouterMethod(){innerService.queryFromOtherDB();// ❌ 即使标注 DS也复用外层连接}DS(other_db)publicvoidqueryFromOtherDB(){returnmapper.selectList(...);// 实际查询的是主库}陷阱二数据源继承原则线程上下文中的数据源标识遵循就近原则-谁最后设置后续就用谁的-通过ThreadLocal管理-子方法继承父方法的数据源设置三、完美解决方案3.1 方案挂起外层事务 显式指定数据源✅ 推荐// 修改 StationServiceImplServicepublicclassStationServiceImplextendsServiceImplStationMapper,StationModel{/** * 重写 list 方法显式指定数据源并挂起外层事务 */OverrideDS(basemete)// 指定数据源Transactional(propagationPropagation.NOT_SUPPORTED)// 关键挂起外层事务publicListStationModellist(WrapperStationModelqueryWrapper){returnsuper.list(queryWrapper);}}步骤操作说明1挂起外层事务NOT_SUPPORTED 暂停主库事务2切换数据源DS(“basemete”) 设置线程上下文为气象库3执行查询使用气象库连接执行 SQL4恢复事务方法结束恢复主库事务3.3 完整业务流程OverrideTransactional(rollbackForException.class)publicvoideditDeviceInfo(DeviceInfoModelidModel,...){// 1. 查询旧数据主库DeviceInfoModeloldDataselectById(idModel.getId());// 2. 判断业务逻辑...// 3. 更新设备信息主库updateById(idModel);// 4. 更新站点绑定内部会挂起事务查询气象库deviceStationConfigService.deviceBindStation(deviceStationConfigModel);// 5. 推送 MQTT 消息mqttSendComponent.publish(...);}3.4 核心公式跨库查询安全 挂起外层事务 显式指定数据源 通过代理调用四、编程式 vs 声明式事务4.1 声明式事务TransactionalTransactional(rollbackForException.class)publicvoiddeclarativeTransaction(){updateMasterData();// 主库queryBasemete();// 跨库查询 - 需要特殊处理updateMasterAgain();// 主库}优点✅ 代码简洁注解即可✅ 自动管理事务边界✅ 统一异常处理缺点❌ 大事务问题整个方法一个事务❌ 跨库困难需要 NOT_SUPPORTED 挂起❌ 灵活性差事务边界不清晰4.2 编程式事务TransactionTemplateAutowiredprivateTransactionTemplatetransactionTemplate;publicvoidprogrammaticTransaction(){// 1. 第一个事务只操作主库transactionTemplate.execute(status-{updateMasterData();returnnull;});// ✅ 立即提交连接释放// 2. 跨库查询无事务状态自由切换ListDatadatastationService.queryFromBasemete();// 3. 第二个事务继续主库操作transactionTemplate.execute(status-{saveResult(data);returnnull;});// ✅ 立即提交}优点✅ 事务边界清晰可见✅ 细粒度控制最小化事务范围✅ 块间自动释放连接跨库更安全✅ 灵活性高缺点❌ 代码侵入性强❌ 多个 execute 块不共享事务❌ 如果中间报错前面的块不会回滚4.3 对比表特性声明式事务编程式事务代码简洁度✅ 注解即可❌ 需要模板代码事务边界❌ 方法级较粗✅ 块级精细跨库支持⚠️ 需要 NOT_SUPPORTED✅ 块间自然隔离灵活性❌ 固定模式✅ 高度灵活异常回滚✅ 自动回滚⚠️ 仅当前块回滚适用场景单库 CRUD跨库复杂业务五、ThreadLocal 的核心作用5.1 ThreadLocal 是什么// 每个线程有自己的独立副本privatestaticfinalThreadLocalStringCONTEXT_HOLDERnewThreadLocal();// 设置值CONTEXT_HOLDER.set(basemete);// 获取值StringdsCONTEXT_HOLDER.get();// basemete// 清除值CONTEXT_HOLDER.remove();5.2 在多数据源中的作用publicclassDynamicRoutingDataSourceextendsAbstractRoutingDataSource{OverrideprotectedObjectdetermineCurrentLookupKey(){// 从 ThreadLocal 获取当前线程的数据源标识returnDynamicDataSourceContextHolder.peek();}}工作流程线程1(Thread-1)├─ThreadLocalMap│ ├─master→Connection(master_db)│ └─basemete→Connection(basemete_db)│ └─ 执行流程:1.A方法:set(master)→ 使用主库2.B方法:set(basemete)→ 切换到气象库3.C方法:get()→ 读取到basemete→ 使用气象库4.B结束:set(master)→ 恢复主库5.3 数据源继承原则Transactional// A方法设置 masterpublicvoidmethodA(){DS(basemete)// B方法设置为 basemeteTransactional(NOT_SUPPORTED)// 挂起A的事务publicvoidmethodB(){// C方法无注解publicvoidmethodC(){// ✅ 继承 B 的数据源设置 → 使用 basemetereturnmapper.selectList(...);}}}核心规则方法C会继承方法B的数据源设置遵循线程上下文继承原则就近原则5.4 挂起事务的本质// NOT_SUPPORTED 的内部实现简化版publicvoidsuspend(){// 1. 保存当前连接ConnectionconnunbindResource(master);// 从 ThreadLocal 移除// 2. 清除线程上下文resources.remove();// ThreadLocal 清空// 3. 返回保存的连接用于恢复returnconn;}publicvoidresume(Connectionconn){// 恢复连接bindResource(master,conn);// 放回 ThreadLocal}关键点✅ 全程同一线程不是开新线程✅ 只是暂时忘记了事务连接✅ 通过 ThreadLocal 的增删改实现切换六、跨库回滚方案对比6.1 问题场景TransactionalpublicvoidcrossDbOperation(){// 事务1主库修改transactionTemplate.execute(status-{deviceMapper.updateById(device);returnnull;});// ✅ 已提交// 查询气象库ListDatadatastationService.queryFromBasemete();// 事务2主库继续修改transactionTemplate.execute(status-{saveRelations(data);returnnull;});// ❌ 如果这里报错}问题第一个事务已经提交无法回滚6.2 方案一调整事务边界✅ 推荐publicvoidsolution1(){// 1. 先查询气象库只读不需要事务ListStationModelstationsstationService.getStations(ids);// 2. 再执行主库事务包含所有写操作transactionTemplate.execute(status-{deviceMapper.updateById(device);saveRelations(stations);returnnull;});// 如果报错两个操作一起回滚 ✅}优点✅ 保证单库操作的原子性✅ 简单可靠无需额外组件缺点⚠️ 需要重新设计业务流程⚠️ 不适用于必须跨库写的场景6.3 方案二手动补偿⚠️ 复杂publicvoidsolution2(){DeviceInfooldDevicedeviceMapper.selectById(device.getId());try{// 主库修改transactionTemplate.execute(status-{deviceMapper.updateById(device);returnnull;});// 气象库修改transactionTemplate.execute(status-{weatherMapper.update(...);returnnull;});}catch(Exceptione){// 补偿恢复旧数据transactionTemplate.execute(status-{deviceMapper.updateById(oldDevice);returnnull;});throwe;}}优点✅ 可以实现近似的事务效果缺点❌ 代码复杂❌ 补偿可能失败双重故障❌ 不是真正的原子性6.4 方案三Seata 分布式事务 重量级GlobalTransactional// Seata 全局事务publicvoiddistributedTransaction(){// 主库操作deviceMapper.updateById(device);// 气象库操作stationService.updateWeatherData(...);// 任何一步失败所有操作都会回滚 ✅}原理XA 两阶段提交2PCTCC 补偿机制Saga 长事务优点✅ 真正的全局事务✅ 自动回滚缺点❌ 引入额外组件架构复杂❌ 性能开销大20%-30%❌ 需要改造现有代码6.5 方案四消息队列最终一致性publicvoideventualConsistency(){// 1. 主库事务transactionTemplate.execute(status-{deviceMapper.updateById(device);mqProducer.send(newDeviceUpdatedEvent(device.getId()));returnnull;});// 2. 异步消费者处理气象库RabbitListenerpublicvoidhandleDeviceUpdated(DeviceUpdatedEventevent){transactionTemplate.execute(status-{weatherMapper.update(...);returnnull;});}}优点✅ 解耦✅ 最终一致性✅ 性能好缺点⚠️ 不是强一致性⚠️ 需要处理幂等性6.6 方案对比表方案一致性复杂度性能适用场景调整事务边界✅ 强一致✅ 低✅ 高跨库查询为主手动补偿⚠️ 近似❌ 高✅ 高补偿逻辑简单Seata✅ 强一致❌ 很高❌ 低金融级要求MQ最终一致⚠️ 最终⚠️ 中✅ 高允许短暂不一致七、最佳实践总结7.1 多数据源事务黄金法则法则说明示例最小事务原则只在真正需要事务的方法上加 Transactional纯查询不加事务单库事务原则一个事务只操作一个数据库避免跨库事务显式挂起原则跨库查询时显式挂起外层事务Propagation.NOT_SUPPORTED数据源就近原则在 Mapper 和 Service 层都标注 DS双重保险查询前置原则跨库查询放在事务外先查后改7.2 常见错误写法// ❌ 错误1在大事务中跨库查询TransactionalpublicvoidbigTransaction(){updateMasterDB();querySlaveDB();// 错库updateMasterDBAgain();}// ❌ 错误2自调用导致 AOP 失效TransactionalpublicvoidmethodA(){this.methodB();// AOP 不生效}DS(other_db)publicvoidmethodB(){/* ... */}// ❌ 错误3NOT_SUPPORTED 用于写操作DS(basemete)Transactional(NOT_SUPPORTED)publicvoidupdateData(){mapper.update(...);// 无法回滚}7.3 正确写法模板// ✅ 推荐的标准写法ServicepublicclassCrossDbServiceImpl{AutowiredprivateTransactionTemplatetransactionTemplate;ResourceprivateOtherDbServiceotherDbService;publicvoidmainMethod(){// 1. 跨库查询无事务ListDatadataotherDbService.queryFromOtherDb();// 2. 本库事务所有写操作transactionTemplate.execute(status-{updateMasterData();saveResult(data);returnnull;});}}ServicepublicclassOtherDbServiceImpl{OverrideDS(other_db)Transactional(propagationPropagation.NOT_SUPPORTED)publicListDataqueryFromOtherDb(){returnmapper.selectList(...);// 正确查询 other_db}}7.4 调试技巧// 1. 打印当前数据源log.info(Current DataSource: {},DynamicDataSourceContextHolder.peek());// 2. 检查事务状态log.info(Is Transaction Active: {},TransactionSynchronizationManager.isActualTransactionActive());// 3. 查看连接的数据库Stringcatalogconnection.getCatalog();log.info(Current Database: {},catalog);八、总结核心知识点回顾Spring 事务传播机制REQUIRED加入现有事务NOT_SUPPORTED挂起现有事务REQUIRES_NEW创建新事务Dynamic DataSource 工作原理基于 AOP 拦截器通过 ThreadLocal 管理数据源标识优先级低于事务管理器ThreadLocal 的作用线程级别的数据源隔离子方法继承父方法的设置挂起事务 暂时清除 ThreadLocal跨库回滚方案调整事务边界推荐手动补偿Seata 分布式事务MQ 最终一致性终极公式跨库查询安全 挂起外层事务 显式指定数据源 通过代理调用 查询前置
Spring Boot 多数据源事务陷阱深度解析
发布时间：2026/6/4 1:03:56
Spring Boot 多数据源事务陷阱深度解析从踩坑到完美解决 目录一、问题背景与核心痛点二、根因深度剖析三、完美解决方案四、编程式 vs 声明式事务五、ThreadLocal 的核心作用六、跨库回滚方案对比七、最佳实践总结一、问题背景与核心痛点1.1 业务场景预警盒子系统需要管理设备信息涉及两个数据库主库warning-master设备信息、设备区域关系等业务数据气象库basemete气象站点信息等基础数据**核心需求**编辑设备信息时需要同时操作两个库。1.2 问题代码ServicepublicclassDeviceInfoServiceImpl{ResourceprivateDeviceStationConfigServicedeviceStationConfigService;OverrideTransactional(rollbackForException.class)// ⚠️ 问题根源publicvoideditDeviceInfo(DeviceInfoModelidModel,...){// 1. 查询旧数据主库✅DeviceInfoModeloldDataselectById(idModel.getId());// 2. 更新设备信息主库✅updateById(idModel);// 3. 更新设备站点绑定主库 气象库❌ 报错deviceStationConfigService.deviceBindStation(deviceStationConfigModel);}}ServicepublicclassDeviceStationConfigServiceImpl{ResourceprivateStationServicestationService;// 操作气象库OverridepublicvoiddeviceBindStation(DeviceStationConfigModelmodel){// ❌ 这里应该查询气象库但实际查询了主库ListStationModelliststationService.list(wrapper);// 错误Table warning_master.station doesnt exist}}1.3 错误现象Error:Tablewarning_master.station doesnt exist明明 StationMapper 标注了 DS(“basemete”)为什么还会查主库二、根因深度剖析2.1 调用链分析editDeviceInfo(Transactional)└─deviceBindStation()└─stationService.list(DS(basemete))2.2 核心原因Spring 事务基于 AOP 代理数据源切换优先级低于事务管理器sequenceDiagram participant Client as 调用方 participant TX as editDeviceInfobr/事务A(主库) participant DS as DynamicDataSource participant DB1 as 主库 participant DB2 as 气象库 Client-TX: 调用 editDeviceInfo activate TX Note over TX,DB1: 开启事务Abr/绑定主库连接 TX-DS: 获取数据源 DS-DB1: 返回主库连接br/(事务已绑定) TX-TX: 调用 deviceBindStation TX-DS: 尝试切换 basemete DS-DB1: ❌ 仍返回主库连接br/(事务未释放) TX-DB1: SELECT * FROM station DB1--TX: Table doesnt exist! deactivate TX2.3 两个致命陷阱陷阱一事务传播导致连接复用Transactional// 外层事务绑定主库连接publicvoidouterMethod(){innerService.queryFromOtherDB();// ❌ 即使标注 DS也复用外层连接}DS(other_db)publicvoidqueryFromOtherDB(){returnmapper.selectList(...);// 实际查询的是主库}陷阱二数据源继承原则线程上下文中的数据源标识遵循就近原则-谁最后设置后续就用谁的-通过ThreadLocal管理-子方法继承父方法的数据源设置三、完美解决方案3.1 方案挂起外层事务 显式指定数据源✅ 推荐// 修改 StationServiceImplServicepublicclassStationServiceImplextendsServiceImplStationMapper,StationModel{/** * 重写 list 方法显式指定数据源并挂起外层事务 */OverrideDS(basemete)// 指定数据源Transactional(propagationPropagation.NOT_SUPPORTED)// 关键挂起外层事务publicListStationModellist(WrapperStationModelqueryWrapper){returnsuper.list(queryWrapper);}}步骤操作说明1挂起外层事务NOT_SUPPORTED 暂停主库事务2切换数据源DS(“basemete”) 设置线程上下文为气象库3执行查询使用气象库连接执行 SQL4恢复事务方法结束恢复主库事务3.3 完整业务流程OverrideTransactional(rollbackForException.class)publicvoideditDeviceInfo(DeviceInfoModelidModel,...){// 1. 查询旧数据主库DeviceInfoModeloldDataselectById(idModel.getId());// 2. 判断业务逻辑...// 3. 更新设备信息主库updateById(idModel);// 4. 更新站点绑定内部会挂起事务查询气象库deviceStationConfigService.deviceBindStation(deviceStationConfigModel);// 5. 推送 MQTT 消息mqttSendComponent.publish(...);}3.4 核心公式跨库查询安全 挂起外层事务 显式指定数据源 通过代理调用四、编程式 vs 声明式事务4.1 声明式事务TransactionalTransactional(rollbackForException.class)publicvoiddeclarativeTransaction(){updateMasterData();// 主库queryBasemete();// 跨库查询 - 需要特殊处理updateMasterAgain();// 主库}优点✅ 代码简洁注解即可✅ 自动管理事务边界✅ 统一异常处理缺点❌ 大事务问题整个方法一个事务❌ 跨库困难需要 NOT_SUPPORTED 挂起❌ 灵活性差事务边界不清晰4.2 编程式事务TransactionTemplateAutowiredprivateTransactionTemplatetransactionTemplate;publicvoidprogrammaticTransaction(){// 1. 第一个事务只操作主库transactionTemplate.execute(status-{updateMasterData();returnnull;});// ✅ 立即提交连接释放// 2. 跨库查询无事务状态自由切换ListDatadatastationService.queryFromBasemete();// 3. 第二个事务继续主库操作transactionTemplate.execute(status-{saveResult(data);returnnull;});// ✅ 立即提交}优点✅ 事务边界清晰可见✅ 细粒度控制最小化事务范围✅ 块间自动释放连接跨库更安全✅ 灵活性高缺点❌ 代码侵入性强❌ 多个 execute 块不共享事务❌ 如果中间报错前面的块不会回滚4.3 对比表特性声明式事务编程式事务代码简洁度✅ 注解即可❌ 需要模板代码事务边界❌ 方法级较粗✅ 块级精细跨库支持⚠️ 需要 NOT_SUPPORTED✅ 块间自然隔离灵活性❌ 固定模式✅ 高度灵活异常回滚✅ 自动回滚⚠️ 仅当前块回滚适用场景单库 CRUD跨库复杂业务五、ThreadLocal 的核心作用5.1 ThreadLocal 是什么// 每个线程有自己的独立副本privatestaticfinalThreadLocalStringCONTEXT_HOLDERnewThreadLocal();// 设置值CONTEXT_HOLDER.set(basemete);// 获取值StringdsCONTEXT_HOLDER.get();// basemete// 清除值CONTEXT_HOLDER.remove();5.2 在多数据源中的作用publicclassDynamicRoutingDataSourceextendsAbstractRoutingDataSource{OverrideprotectedObjectdetermineCurrentLookupKey(){// 从 ThreadLocal 获取当前线程的数据源标识returnDynamicDataSourceContextHolder.peek();}}工作流程线程1(Thread-1)├─ThreadLocalMap│ ├─master→Connection(master_db)│ └─basemete→Connection(basemete_db)│ └─ 执行流程:1.A方法:set(master)→ 使用主库2.B方法:set(basemete)→ 切换到气象库3.C方法:get()→ 读取到basemete→ 使用气象库4.B结束:set(master)→ 恢复主库5.3 数据源继承原则Transactional// A方法设置 masterpublicvoidmethodA(){DS(basemete)// B方法设置为 basemeteTransactional(NOT_SUPPORTED)// 挂起A的事务publicvoidmethodB(){// C方法无注解publicvoidmethodC(){// ✅ 继承 B 的数据源设置 → 使用 basemetereturnmapper.selectList(...);}}}核心规则方法C会继承方法B的数据源设置遵循线程上下文继承原则就近原则5.4 挂起事务的本质// NOT_SUPPORTED 的内部实现简化版publicvoidsuspend(){// 1. 保存当前连接ConnectionconnunbindResource(master);// 从 ThreadLocal 移除// 2. 清除线程上下文resources.remove();// ThreadLocal 清空// 3. 返回保存的连接用于恢复returnconn;}publicvoidresume(Connectionconn){// 恢复连接bindResource(master,conn);// 放回 ThreadLocal}关键点✅ 全程同一线程不是开新线程✅ 只是暂时忘记了事务连接✅ 通过 ThreadLocal 的增删改实现切换六、跨库回滚方案对比6.1 问题场景TransactionalpublicvoidcrossDbOperation(){// 事务1主库修改transactionTemplate.execute(status-{deviceMapper.updateById(device);returnnull;});// ✅ 已提交// 查询气象库ListDatadatastationService.queryFromBasemete();// 事务2主库继续修改transactionTemplate.execute(status-{saveRelations(data);returnnull;});// ❌ 如果这里报错}问题第一个事务已经提交无法回滚6.2 方案一调整事务边界✅ 推荐publicvoidsolution1(){// 1. 先查询气象库只读不需要事务ListStationModelstationsstationService.getStations(ids);// 2. 再执行主库事务包含所有写操作transactionTemplate.execute(status-{deviceMapper.updateById(device);saveRelations(stations);returnnull;});// 如果报错两个操作一起回滚 ✅}优点✅ 保证单库操作的原子性✅ 简单可靠无需额外组件缺点⚠️ 需要重新设计业务流程⚠️ 不适用于必须跨库写的场景6.3 方案二手动补偿⚠️ 复杂publicvoidsolution2(){DeviceInfooldDevicedeviceMapper.selectById(device.getId());try{// 主库修改transactionTemplate.execute(status-{deviceMapper.updateById(device);returnnull;});// 气象库修改transactionTemplate.execute(status-{weatherMapper.update(...);returnnull;});}catch(Exceptione){// 补偿恢复旧数据transactionTemplate.execute(status-{deviceMapper.updateById(oldDevice);returnnull;});throwe;}}优点✅ 可以实现近似的事务效果缺点❌ 代码复杂❌ 补偿可能失败双重故障❌ 不是真正的原子性6.4 方案三Seata 分布式事务 重量级GlobalTransactional// Seata 全局事务publicvoiddistributedTransaction(){// 主库操作deviceMapper.updateById(device);// 气象库操作stationService.updateWeatherData(...);// 任何一步失败所有操作都会回滚 ✅}原理XA 两阶段提交2PCTCC 补偿机制Saga 长事务优点✅ 真正的全局事务✅ 自动回滚缺点❌ 引入额外组件架构复杂❌ 性能开销大20%-30%❌ 需要改造现有代码6.5 方案四消息队列最终一致性publicvoideventualConsistency(){// 1. 主库事务transactionTemplate.execute(status-{deviceMapper.updateById(device);mqProducer.send(newDeviceUpdatedEvent(device.getId()));returnnull;});// 2. 异步消费者处理气象库RabbitListenerpublicvoidhandleDeviceUpdated(DeviceUpdatedEventevent){transactionTemplate.execute(status-{weatherMapper.update(...);returnnull;});}}优点✅ 解耦✅ 最终一致性✅ 性能好缺点⚠️ 不是强一致性⚠️ 需要处理幂等性6.6 方案对比表方案一致性复杂度性能适用场景调整事务边界✅ 强一致✅ 低✅ 高跨库查询为主手动补偿⚠️ 近似❌ 高✅ 高补偿逻辑简单Seata✅ 强一致❌ 很高❌ 低金融级要求MQ最终一致⚠️ 最终⚠️ 中✅ 高允许短暂不一致七、最佳实践总结7.1 多数据源事务黄金法则法则说明示例最小事务原则只在真正需要事务的方法上加 Transactional纯查询不加事务单库事务原则一个事务只操作一个数据库避免跨库事务显式挂起原则跨库查询时显式挂起外层事务Propagation.NOT_SUPPORTED数据源就近原则在 Mapper 和 Service 层都标注 DS双重保险查询前置原则跨库查询放在事务外先查后改7.2 常见错误写法// ❌ 错误1在大事务中跨库查询TransactionalpublicvoidbigTransaction(){updateMasterDB();querySlaveDB();// 错库updateMasterDBAgain();}// ❌ 错误2自调用导致 AOP 失效TransactionalpublicvoidmethodA(){this.methodB();// AOP 不生效}DS(other_db)publicvoidmethodB(){/* ... */}// ❌ 错误3NOT_SUPPORTED 用于写操作DS(basemete)Transactional(NOT_SUPPORTED)publicvoidupdateData(){mapper.update(...);// 无法回滚}7.3 正确写法模板// ✅ 推荐的标准写法ServicepublicclassCrossDbServiceImpl{AutowiredprivateTransactionTemplatetransactionTemplate;ResourceprivateOtherDbServiceotherDbService;publicvoidmainMethod(){// 1. 跨库查询无事务ListDatadataotherDbService.queryFromOtherDb();// 2. 本库事务所有写操作transactionTemplate.execute(status-{updateMasterData();saveResult(data);returnnull;});}}ServicepublicclassOtherDbServiceImpl{OverrideDS(other_db)Transactional(propagationPropagation.NOT_SUPPORTED)publicListDataqueryFromOtherDb(){returnmapper.selectList(...);// 正确查询 other_db}}7.4 调试技巧// 1. 打印当前数据源log.info(Current DataSource: {},DynamicDataSourceContextHolder.peek());// 2. 检查事务状态log.info(Is Transaction Active: {},TransactionSynchronizationManager.isActualTransactionActive());// 3. 查看连接的数据库Stringcatalogconnection.getCatalog();log.info(Current Database: {},catalog);八、总结核心知识点回顾Spring 事务传播机制REQUIRED加入现有事务NOT_SUPPORTED挂起现有事务REQUIRES_NEW创建新事务Dynamic DataSource 工作原理基于 AOP 拦截器通过 ThreadLocal 管理数据源标识优先级低于事务管理器ThreadLocal 的作用线程级别的数据源隔离子方法继承父方法的设置挂起事务 暂时清除 ThreadLocal跨库回滚方案调整事务边界推荐手动补偿Seata 分布式事务MQ 最终一致性终极公式跨库查询安全 挂起外层事务 显式指定数据源 通过代理调用 查询前置
了！详解MySQL、MyBatis与Java类型映射的“潜规则”与最佳实践)
