企业官网建设流程全解析

1. 问题背景：接口里同时操作MySQL和MongoDB，为什么事务成了老大难

先还原一个典型场景。你在写一个订单创建接口，业务逻辑是这样的：先往MySQL的orders表插入一条订单记录，然后再往MongoDB的order_logs集合写入一条流水日志。单看任何一步都没问题，MySQL这边用Spring的@Transactional一包，出错了自动回滚。MongoDB那边单独操作也没毛病。但问题出在两个数据库同时参与一个接口调用时——如果MySQL插入成功了，MongoDB写入却抛了异常，这时候该怎么办？

我最早遇到这个问题是在做一个电商中台项目，订单主数据在MySQL，商品快照、埋点日志、用户操作轨迹放在MongoDB，一个下单接口要同时写两边的数据。上线前测试环境一切正常，上线后高峰期出现了几十条订单有MySQL记录、MongoDB没日志的脏数据。排查的时候特别痛苦，因为单看MySQL是完整的，单看MongoDB也是完整的，只有把两边数据放在一起比对才能发现问题。这也是跨数据库事务最恶心的点：问题不会立刻暴露，而是像欠了债一样累积，等你想起来对账的时候，已经是一笔烂账了。

这个问题的本质是什么？一句话概括：MySQL事务和MongoDB事务各自只能保证自己节点内的ACID，跨节点的原子性在应用层没有天然机制兜底。传统关系型数据库有XA两阶段提交协议，但一是实现复杂、性能损耗大，二是MongoDB虽然从4.0版本开始支持多文档事务，但它的事务模型和MySQL的XA协议完全是两码事，两者之间没有一个标准的全局事务协调器。

所以，做接口开发的人必须建立这样一个认知：只要一个接口里涉及多个数据源，你就等于进入了分布式事务的领域。哪怕你的接口只有一个方法、几个SQL和几条MongoDB操作，它也是一个微缩版的分布式事务问题。这篇文章就围绕这个问题，从原理到实操，把我在实际项目中踩过的坑和沉淀下来的方案完整过一遍。

2. 先搞清楚两个数据库在事务能力上的本质差异

2.1 MySQL InnoDB事务：成熟、完备、依赖回滚日志

MySQL默认使用InnoDB存储引擎，事务机制经过二十多年迭代已经非常成熟。它的核心是redo log和undo log的配合：redo log保证已提交事务的持久性，undo log负责记录事务执行前的数据镜像，一旦事务需要回滚，就通过undo log把数据恢复到操作之前的状态。

写一个例子。你在一个事务里执行了三条SQL：

START TRANSACTION; INSERT INTO orders (id, user_id, amount) VALUES (1, 1001, 99.00); UPDATE user_balance SET balance = balance - 99.00 WHERE user_id = 1001; INSERT INTO order_logs (order_id, action) VALUES (1, 'CREATE'); COMMIT;

如果第三条SQL因为某个字段超长报错了，InnoDB会自动把前两条SQL的影响也撤销掉。这个能力是数据库内核提供的，应用层不需要写任何回滚代码。

2.2 MongoDB事务：4.0之后才有，约束条件多

MongoDB从4.0版本才开始支持多文档事务，而且只支持副本集模式；4.2版本才扩展到分片集群。但它的使用限制非常多：

• 事务默认超时时间为60秒，超过时间事务自动中止。
• 事务期间不能修改集合结构（不能建索引、不能删除集合）。
• 写入操作要求事务内的所有文档必须存在于同一个分片（如果使用分片集群）。
• 事务内的读操作默认读关注为primary，不支持从节点读取。

更重要的是，MongoDB的事务是基于会话（session）的。你在代码里开启一个事务时，必须显式传入session参数，所有操作都得绑定这个session。这和MySQL那种隐式事务的感觉完全不同。

// MongoDB事务的标准写法（Java驱动） ClientSession session = mongoClient.startSession(); try { session.startTransaction(); collection.insertOne(session, doc1); collection.insertOne(session, doc2); session.commitTransaction(); } catch (Exception e) { session.abortTransaction(); } finally { session.close(); }

注意到没有，MongoDB的事务代码比MySQL繁琐得多。而且，如果你不小心漏传了session，操作不会报错，而是直接以非事务方式执行了——这个坑非常隐蔽。

2.3 为什么两个数据库无法自动联动回滚

MySQL没有能力感知MongoDB的事务状态，MongoDB也不知道MySQL那边发生了什么。两者之间没有共享的事务协调器。所以，当你在一个接口里先写MySQL再写MongoDB，然后MongoDB写入失败，MySQL那边已经提交的事务是不可能自动回滚的。

这里需要区分一个概念：你如果在Spring的@Transactional方法里既操作了MySQL的Mapper，又操作了MongoTemplate，Spring会不会自动帮你把两个都回滚？答案是：Spring只能回滚实现了Spring事务管理接口的数据源，对于MongoDB，Spring Data MongoDB确实也提供了一部分事务支持，但前提是它要接管MongoDB的事务生命周期，并且你要使用MongoDB的session开启事务。Spring不会因为你MySQL抛了异常，就自动去调用MongoDB的abortTransaction。反过来也一样。

打个比方：你请了两个施工队分别负责水电和木工，结果木工做坏了，水电工已经收工走人。你不可能指望水电工自己回头把已经铺好的管线拆了重新来——除非你有办法通知到他。这里的"通知机制"，就是分布式事务中所谓的协调器，而Spring默认并没有这个东西。

3. 接口层处理跨库事务的六种常见方案与选型权衡

既然数据库层面无法自动联动，那就只能在应用层想办法。这六种方案我都在真实项目中验证过或调研过，各有适用场景，没有银弹。

3.1 两阶段提交（XA）：理论上最正统，实践中几乎不用

XA协议是X/Open组织提出的分布式事务规范，核心思想是通过事务管理器协调多个资源管理器完成两阶段提交：第一阶段所有参与者各自执行事务并锁定资源（prepare），第二阶段事务管理器统一决定提交或回滚（commit/rollback）。

MySQL InnoDB支持XA事务，Spring通过JTA（Java Transaction API）可以管理多个XA数据源。但MongoDB不支持标准的XA协议，所以这个方案在MySQL+MongoDB的组合下基本无法落地。即便同样是两个MySQL数据库，我也建议慎用XA，因为两阶段提交的锁定时间很长，在高并发接口下会产生大量的锁等待和超时，性能损耗非常可观。

3.2 本地消息表：经典可靠方案，适合中等并发

这个方案的核心思路是：把"保证多数据源一致"这件事，转化为"保证本地数据库事务+异步消息投递"。

具体做法：

1. 在MySQL中创建一个消息表（message_outbox），和业务表放在同一个MySQL实例里。
2. 在同一个本地事务中写入业务数据和消息记录。
3. 后台有一个定时任务，扫描message_outbox里状态为"待发送"的记录，把消息发送到MQ（比如RocketMQ、RabbitMQ）。
4. 消费者收到消息后执行MongoDB的写入操作。
5. 写成功后，回调接口修改消息状态为"已发送"；写失败则重试。

这个方案的好处是，MySQL那边的事务是真正的本地事务，可靠度极高。MongoDB的写入变成了一种异步补偿动作，即使失败也可以通过重试机制最终达成一致。

但缺点也很明显：接口的实时性变差了。原本一条接口请求直接写两个库，现在变成先写MySQL，再通过MQ异步写MongoDB，数据最终一致的时间取决于消息投递和消费的速度。

3.3 事务消息：消息队列支持的事务方案

RocketMQ的事务消息本质上是"本地消息表方案"的中间件化。它把消息表的管理移植到了MQ服务端，但应用层仍需实现半消息（half message）的回查逻辑。这个方案比手动建表要省心，但增加了对MQ中间件版本的依赖。如果你的项目已经有RocketMQ，我推荐优先考虑这种方式。

3.4 SAGA事务模式：拆解为多个子事务，逐层补偿

SAGA模式来源于分布式事务的学术研究，核心思想是把一个全局事务拆分为多个子事务，每个子事务有对应的补偿操作。比如一个下单接口拆成：创建订单（MySQL）→ 扣减库存（MySQL）→ 写操作日志（MongoDB）。任何一个子事务失败，就反向执行前面所有成功子事务的补偿操作。

这种模式非常契合MySQL+MongoDB的场景，因为它的本质就是每个参与方管理自己的事务，应用层通过补偿逻辑来兜底。但SAGA要求你对每个子事务都设计出对应的补偿逻辑，比如创建订单的补偿是删除订单，扣减库存的补偿是加回库存。补偿逻辑写起来很繁琐，而且补偿操作本身也需要具备幂等性。

3.5 最终一致性：先写主库，再异步同步

如果MongoDB里面存的不是核心业务数据（比如日志、流水、快照），那可以考虑把它降级为异步同步。核心思路是：接口只保证MySQL的强一致，MongoDB的数据通过后续的定时任务或MQ进行同步。这可能听起来像是偷懒，但结合真实业务来说，很多场景根本不需要MongoDB和MySQL保持强一致。

比如订单日志，用户下单后立刻查不到日志，或者日志延迟几秒才出现，对用户无感知，对业务也基本无影响。这种方案代码量最少、性能影响最小，是我在实际项目中用得最多的。

3.6 保持一致性的兜底方案：对账与修复任务

无论你选了哪种方案，我都建议在系统层面加一道对账机制。定期（比如每5分钟）跑一个比对任务，找出MySQL有记录但MongoDB没记录的数据，自动或人工触发生成缺失的MongoDB文档。这个方案不是解决事务问题的，而是解决"万一前面的方案也有漏洞"的问题。算是最后一道保险。

3.7 方案选型对比表

4. 实操方案：接口中用一个可靠且改动可控的回滚机制

现在具体到代码层面。考虑到大多数团队的技术栈是Spring Boot + MyBatis + Spring Data MongoDB，我给你一套已经在生产环境跑过很久的方案：本地事务 + Mongo手动提交/回滚 + 补偿兜底。

这个方案不需要额外引入MQ，也不用写太复杂的SAGA编排，适合业务接口数量在几十个到上百个的中型项目。

4.1 整体设计思路

核心策略是**"MongoDB后写、失败补偿"**：

1. 先在自己的MySQL事务里完成所有MySQL侧的写入，并立刻提交。
2. 然后执行MongoDB的写入操作，通过session开启事务，写成功后提交。
3. 如果MongoDB写入失败，则触发MySQL侧的补偿操作，把刚才在MySQL中写入的数据删除或标记为失效。

这样，MySQL是"正向事务"，MongoDB是"尽力而为"，如果MongoDB失败，补偿逻辑来修正。相比先写MongoDB再写MySQL的方案，这个顺序有一个好处：MySQL是主要数据源，可靠性更高，先提交MySQL可以降低主数据丢失的风险。

4.2 代码骨架示例

@Service @Slf4j public class OrderServiceImpl implements OrderService { @Autowired private OrderMapper orderMapper; @Autowired private MongoTemplate mongoTemplate; @Autowired private MongoTransactionManager mongoTransactionManager; @Override @Transactional(rollbackFor = Exception.class) public void createOrder(OrderCreateRequest request) { // Step 1: 生成主订单数据 OrderDO order = new OrderDO(); order.setOrderId(request.getOrderId()); order.setUserId(request.getUserId()); order.setAmount(request.getAmount()); order.setStatus("CREATED"); orderMapper.insert(order); // Step 2: 写MongoDB流水（先不入集合，等MySQL提交后再写） // 这里不做任何操作 } }

上面这段代码只是最基础的MySQL本地事务。下面要做的就是改造，把MongoDB的写入挪到MySQL事务提交之后。

4.3 使用TransactionSynchronizationManager在事务提交后执行MongoDB操作

Spring提供了TransactionSynchronizationManager，可以注册一个同步回调，在当前事务提交后执行后续动作。这是一个非常实用的机制，很多资深开发也未必用过。

@Service @Slf4j public class OrderServiceImpl implements OrderService { @Autowired private OrderMapper orderMapper; @Autowired private MongoTemplate mongoTemplate; @Override @Transactional(rollbackFor = Exception.class) public void createOrder(OrderCreateRequest request) { OrderDO order = buildOrderDO(request); orderMapper.insert(order); // 注册事务同步回调：在MySQL事务提交后执行MongoDB写入 TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() { @Override public void afterCommit() { try { // 这个回调里执行MongoDB写入 OrderLogDO logDO = buildOrderLogDO(order); mongoTemplate.insert(logDO, "order_logs"); } catch (Exception e) { log.error("写入MongoDB失败, orderId={}", request.getOrderId(), e); // 这里需要触发补偿机制，将MySQL中的记录标记为失效 orderMapper.markFailed(request.getOrderId()); } } }); } }

这段代码的关键在于：afterCommit()方法里的逻辑不受MySQL本地事务的控制，MySQL事务已经提交了，所以这里的异常不会触发MySQL回滚。补偿动作就得自己写。

4.4 手动控制MongoDB事务（如果MongoDB也是核心数据源）

如果MongoDB里的数据也很核心，不能简单靠重试来兜底，那就需要显式开启MongoDB的事务。这里推荐使用MongoTransactionManager，它可以和Spring的事务抽象集成，但要留意它的配置方式。

@Configuration public class MongoConfig { @Bean public MongoTransactionManager transactionManager(MongoDatabaseFactory dbFactory) { return new MongoTransactionManager(dbFactory); } }

然后在Service里使用@Transactional注解，但是是MongoDB的事务管理器，注意要和MySQL的事务管理器区分开。实际开发里，我不建议在同一个方法上同时标两个@Transactional，容易引起混乱。更稳妥的做法是拆分两个方法，一个管MySQL，一个管MongoDB，在调用层做编排。

@Service public class OrderCreateService { @Autowired private OrderTransactionService orderTransactionService; @Autowired private MongoLogService mongoLogService; public void createOrder(OrderCreateRequest request) { // 1. MySQL本地事务 orderTransactionService.createOrderInMySql(request); // 2. MongoDB事务，失败时调用补偿 try { mongoLogService.writeLog(request.getOrderId(), "CREATE"); } catch (Exception e) { // 补偿：更新MySQL订单状态为LOG_WRITE_FAILED orderTransactionService.markLogWriteFailed(request.getOrderId()); throw new BizException("订单创建成功，但日志写入失败"); } } }

4.5 补偿操作必须支持的幂等性设计

补偿操作很容易踩的坑是重复执行。比如MongoDB写入实际成功了，但网络超时导致接口报错，补偿逻辑又执行了一次。这时候如果补偿逻辑是"删除MongoDB日志"，就可能把已经写好的日志删掉，造成数据缺失。

所以，所有补偿操作都必须支持幂等。简单来说，不管你执行多少次，结果都一样。

设计方式有两种：

• 状态机方案：在MySQL的orders表加一个status字段，订单状态流转是单向的：CREATED → LOG_WRITTEN → COMPLETED。补偿操作只有在status=CREATED时才能执行，执行后变为LOG_WRITTEN_FAILED。这样即使补偿被触发两次，第二次发现状态不匹配，直接跳过。
• 唯一索引方案：在MongoDB的order_logs集合里给orderId加唯一索引。补偿操作先尝试查询，如果已存在则直接返回成功。

两种方案我都用过，更推荐状态机方案，因为它在MySQL层面就把补偿的边界限制住了，逻辑清晰，排查问题也方便。

5. 常见问题与排查技巧实录

5.1 问题现象：MySQL有数据，MongoDB没有数据

这是最常见的现象。出现原因一般有三种：MongoDB写入抛出了异常但被吞掉了、补偿逻辑执行失败没重试、MongoDB写入超时但实际已经成功（假失败）。

排查思路是：先看应用日志里有没有MongoDB相关的报错记录。如果没有，再看补偿逻辑是否正确执行。如果补偿逻辑也执行了，那就要怀疑是不是"假失败"——MongoDB写入成功但响应超时。

针对"假失败"，最简单的排查方式是去MongoDB里直接查一下orderId对应的数据是否存在。如果存在，就说明是假失败，补偿逻辑要设计成幂等的，这样不会造成重复数据。

5.2 问题现象：MongoDB有数据，MySQL没有数据

这种情况多半是代码执行顺序反了，先写了MongoDB，再写MySQL。MySQL事务回滚后，MongoDB的数据就成了"孤儿数据"。所以开发规范上一定要明确：MongoDB必须是后写的一方。

如果代码已经上线且不方便调整执行顺序，可以通过定时任务扫描MongoDB里最近10分钟写入的日志数据，反查MySQL，如果没有关联订单则补发告警或自动删除。

5.3 问题现象：MongoDB事务开启时报错

使用MongoDB事务时，最常见的报错是Transaction numbers are only allowed on a replica set member or mongos。这个报错的意思是你的MongoDB运行在Standalone模式，不支持事务。

解决方法是把MongoDB改成副本集模式，哪怕是单节点副本集也行。具体操作是在MongoDB的配置文件中添加replication配置：

replication: replSetName: rs0

然后重启服务，执行一次初始化：

rs.initiate()

很多人在本地开发环境遇到这个问题，多半是因为图省事直接用的是Standalone模式。改用副本集模式后，事务功能就可以使用了。

5.4 问题现象：Spring事务和多数据源配置冲突

项目里同时配置了MySQL数据源和MongoDB，Spring的@Transactional注解默认绑定的是DataSourceTransactionManager。如果你没有指定事务管理器，Spring会按照类型自动装配，但一旦有两个事务管理器（比如MySQL的和MongoDB的），必须明确指定。

@Transactional(transactionManager = "mysqlTransactionManager", rollbackFor = Exception.class)

不要图省事省略transactionManager参数，否则运行期可能出现事务不生效或者事务管理器错乱的诡异问题。

5.5 幂等性设计不彻底，导致重复补偿

接口层需要保证幂等，这是一个老生常谈但经常被忽略的点。尤其涉及跨库操作时，一个请求由于网络原因被前端重试两次，如果接口没有幂等控制，MySQL和MongoDB各写了两份数据。

我的做法是在接口入口处增加一个幂等判断：根据业务唯一键（比如orderId），在MySQL中查一下订单是否已存在，存在则直接返回已有结果。这个方法虽然简单，但能挡掉大部分重复请求。

5.6 监控与告警：如何快速发现跨库数据不一致

人工比对数据不现实，最好做成自动化监控。我在项目中实现过一个简易的对账任务，每10分钟跑一次：

1. 从MySQL的orders表查出最近10分钟内状态为CREATED或COMPLETED的订单。
2. 根据订单ID集合查MongoDB的order_logs，比对是否存在。
3. 如果订单存在但日志不存在，发告警通知。

这段对账逻辑不复杂，但价值很高。它可以发现那些"补偿逻辑连自己都没处理好的情况"，是分布式事务体系的最后一道保险。

6. 一些值得注意的底层原理解读与性能影响

6.1 @Transactional为什么不能跨数据源回滚

很多初学者会有一个误解：在一个方法上加了@Transactional，是不是所有数据库操作都能回滚？不是。@Transactional注解背后依靠的是Spring的事务管理器，每个数据源需要独立的事务管理器，事务边界是随着事务管理器走的。

当你调用一个Mapper方法时，事务是与当前的DataSource绑定的。你调用MongoTemplate时，MongoDB的操作走的是MongoDB的事务管理器。两个事务管理器各管各的，没有统一的提交或回滚入口。这也是我在前面强调"必须自己写补偿逻辑"的根本原因。

6.2 MongoDB事务的性能特征与使用限制

MongoDB事务引入了一个隐式的"快照隔离"机制，在事务执行期间，所有读操作只能读到一个快照的数据，写操作之间会有锁冲突。如果你的事务写入了大量文档，性能会显著下降。

我做过一次压测：在MongoDB 5.0副本集模式下，单文档写入的非事务操作TPS大约12000，开启事务后TPS降到2800左右。相当于打了2折到3折。所以，不要轻易把高频写入操作放到MongoDB事务里，能用单文档原子操作解决的，尽量用单文档操作。

比如，更新一个嵌套字段可以用$set，给某个数组追加一个元素可以用$push，这些都能在单文档层面保证原子性，完全不需要开启跨文档事务。

6.3 连接池资源占用与事务超时

MongoDB事务在执行期间会占用一个连接资源。如果一个接口开启了事务但处理速度很慢，连接池会被迅速耗尽，引起雪崩。

解决方法是给MongoDB事务设置合理的超时时间，比如5秒。在Spring Data MongoDB中可以通过配置spring.data.mongodb.transaction-timeout上限来控制，也可以在代码中显式设置Session的事务选项。

Java驱动的写法：

TransactionOptions txnOptions = TransactionOptions.builder() .maxCommitTime(Duration.ofSeconds(5)) .build(); session.startTransaction(txnOptions);

同理，MySQL这边也要设置合理的@Transactional超时时间，防止长事务攒一堆未提交数据。我一般会把接口级别的超时时间设置在10秒以内。

7. 更进一步：什么时候要重构接口设计

前面讲的都是在"接口必须同时操作两个数据库"的前提下做文章。但有些时候，更好的解法是从接口设计层面规避掉跨库事务。

7.1 将强一致操作聚合到单一数据库

如果业务允许，尽量把强一致的数据都放在MySQL里，MongoDB只存储非核心数据。比如订单业务中，orders表可以冗余一个字段存储JSON格式的商品快照，而不是把商品快照单独放到MongoDB。虽然这违反了"第三范式"，却换来了接口的简单性和强一致性。

7.2 用事件驱动替代同步写入

如果你是用MongoDB存日志和流水，完全可以改成发送一个领域事件到MQ，由MQ的消费者异步写入。这样接口本身不需要感知MongoDB的存在，事务问题直接消失。

7.3 评估一下：你的MongoDB到底是不是刚需

有些团队在项目中引入MongoDB，其实只用了它存储JSON文档、日志、统计聚合数据。但在只有这类需求时，MySQL的JSON字段类型（8.0以上版本）或者PostgreSQL的JSONB也能胜任。与其背上跨库事务的包袱，还不如从一开始就统一数据源。

我在一个项目中就做过这样的迁移：把MongoDB中的用户行为日志迁到了MySQL，用一张log表加一个script字段存JSON，虽然单表数据量增长了一些，但查询能力并没有下降，反而因为不用跨库，整个系统的稳定性和可维护性都有了明显提升。

8. 针对MySQL和MongoDB安装部署与运维层面的补充

文章最后补充一块很多人会遇到的问题，因为它和"事务回滚"在运维层面的表现息息相关：如果你的MongoDB安装部署不对，很多事务配置根本不会生效。

8.1 MongoDB必须使用副本集模式

前面提到过，MongoDB事务必须运行在副本集或分片集群上。很多新手按照教程安装完MongoDB，默认跑的是Standalone模式，结果在代码里一开启事务就报错。把MongoDB切换到单节点副本集的方法，前面已经给过，这里不再重复。

8.2 MySQL的隔离级别对回滚行为的影响

MySQL默认的隔离级别是Repeatable Read（可重复读）。在这个级别下，事务内的所有查询都基于同一个快照，所以如果事务中途有其他请求修改了数据，你是感知不到的。这会导致一个问题：补偿逻辑里查询状态时可能读到旧数据。

举个例子：订单事务内，你给订单状态改成了CREATED，然后执行MongoDB写入失败，事务回滚。此时如果另一个线程修改了订单状态为COMPLETED，补偿逻辑再去查订单时，可能因为隔离级别的限制，查到的还是旧状态。解决这个问题的方法是补偿逻辑使用独立的新事务去查询（比如使用REQUIRES_NEW传播级别），确保读到最新的已提交数据。

8.3 MySQL事务开启时需要注意的DDL问题

MySQL在事务中执行DDL语句（比如ALTER TABLE、CREATE INDEX）会造成隐式提交。如果你在一段事务逻辑里先插入业务数据，再执行了一条DDL语句，事务会被自动切割，前面的写操作已经提交了，后面的写操作如果报错，是无法回滚到最开始的。这个问题在老项目中非常普遍，排查起来也很隐蔽。建议开发规范明确：事务方法内禁止执行业务DDL操作。

8.4 数据库连接参数的正确设置

MySQL的JDBC连接串中，autoReconnect参数要设置为true，maxReconnectAttempts要合理配置。否则数据库连接断开时，在事务内执行的第一个SQL可能直接抛异常，而Spring可能还会尝试重试，导致同一个事务执行了两遍写操作。

MongoDB连接串方面，注意不要设置过小的maxPoolSize，因为MongoDB事务期间连接是独占的，如果连接池过小，并发一上来就会因为获取不到连接而超时。推荐设置为100以上，具体取决于你的服务部署实例数和并发量。

9. 用一个完整的故障处理案例串起整个思路

最后分享一个我之前处理过的线上故障，把这个问题的完整排查和解决过程走一遍。

9.1 故障现象

某天下午，运营反馈后台订单列表里，有部分订单的详情页打开后日志区域是空的。这些订单的MySQL记录状态是CREATED，但MongoDB里没有对应的订单日志。运营怀疑系统丢了数据，要求排查。

9.2 排查过程

第一步，我先查了应用日志。发现在订单创建接口的MongoDB写入处有报错：MongoTimeoutException: Timed out after 30000 ms。这个报错信息表明MongoDB写操作超时了。

第二步，我查了MongoDB的监控面板，发现当时MongoDB的CPU使用率达到了90%，慢查询明显增多。进一步排查发现有个后台统计任务在MongoDB上跑了一个大范围的聚合查询，占用了大量系统资源。

第三步，我确认了代码逻辑：MongoDB写入是在Spring事务的afterCommit回调中执行的。虽然MongoDB写入失败了，代码也执行了补偿逻辑，把MySQL订单状态标记为LOG_WRITE_FAILED，但运营看到的那批订单状态还是CREATED。原因是——补偿逻辑只处理了单条数据，但那个时间段因为MongoDB超时，补偿逻辑本身也发生了超时，结果导致订单状态根本没来得及更新。

9.3 解决方案

我做了两件事：

第一，把补偿逻辑改为异步执行。MongoDB写入失败后，把orderId丢进一个本地内存队列（或者直接业务库建一张失败重试表），由单独的线程池负责重试，重试次数上限为3次。这样即使第一次补偿失败，后面还有机会。

第二，为MongoDB的数据一致性增加了一个对账任务，每10分钟扫描一次失败记录，把缺失的日志补写进去。

这个故障的根本原因，其实就是"跨库操作没有兜底机制"。MySQL那边事务很干净地提交了，MongoDB这边因为外部因素失败了，最后全靠补偿逻辑硬抗。一旦补偿逻辑也出问题，数据一致性就破了。所以，事务+补偿+对账，三层缺一不可。

10. 我的经验总结与建议

做了这么多跨库事务的项目，我最直观的体会是：不要在架构层面追求不切实际的"强一致"，要在设计层面尽量规避跨库操作。

如果你确实无法避免一个接口同时操作MySQL和MongoDB，那就按照这个优先级来做决策：

1. 能异步的就异步。非核心数据、日志类数据、用户行为数据，全部走MQ异步写入，接口本身只操作MySQL。这是最简单、最稳妥的方案。
2. 不能异步的，优先考虑"MySQL先行 + 补偿逻辑"的模式，并把补偿逻辑做成幂等、可重试的。
3. 两个库都需要强一致的场景，要回到业务层面问一问：这两个数据源真的需要同时更新吗？能不能把数据合并到一个库里？

还有一个小技巧：写代码时，把所有跨库操作集中在独立的Service方法中，不要散落到业务代码各处。比如专门写一个OrderCrossStoreService，统一管理"先写MySQL再写MongoDB"的编排和补偿。这样即使出了问题，排查范围也小很多。

我开发过程中最常提醒自己的三句话：

• 一个接口只保一个强事务，另一个数据库是"追求最终一致"。
• 每一条补偿逻辑都必须能重试、可幂等，否则就是在给自己埋雷。
• 监控和告警不是可选项，是分布式事务方案的标配。

这些经验听起来朴素，但对线上稳定性至关重要。跨库事务问题从来不是写几行代码就能一劳永逸的，它是一个需要从设计、编码、监控、运维多角度持续完善的系统工程。