消息已经被发出去，但数据库里找不到对应的订单记录。下游服务消费了这条消息，报错、重试，最终触发了客户投诉和人工干预。这就是常见的“数据没落地，消息先飞走”问题，日志里还伴随着一堆“
TransactionSynchronization not invoked after completion”的错误提示。
回溯这件事，先说得更广一些。在分布式业务里，许多操作不是单一数据库写入就结束的，常常会有后续的副作用：发通知、推到消息队列、更新搜索索引等。要保证这些副作用只在数据真正写入后发生，需要让副作用的触发和事务提交紧密绑定。问题出在多数实现里，开发者把“写库”和“发消息”按顺序写在同一个方法里，但这两个动作的实际执行时间并不必定按代码顺序完结。数据库写操作被事务包裹，真正落库在提交时刻；而发消息的调用一旦执行，就可能把消息推送出去，不会由于之后的事务回滚自动撤回。结果就是——消费方找不到数据，出现异常。
具体到一个电商下单场景：用户点击下单，系统先在数据库里插入订单记录，然后调用一个发送消息到MQ的接口。表面上看一切直观，但在事务还没提交的瞬间，发送接口可能已经把消息发出。如果随后事务由于某种缘由回滚（列如库存校验失败或数据库写入冲突），订单记录被撤销，但消息已经在队列里等着被消费。消费方拿不到订单，库存或后续流程出现异常，最终可能导致超卖、重复扣款或业务不一致。出现问题时，日志会提示事务同步相关的警告或错误，这就是那句“
TransactionSynchronization not invoked after completion”常常出现的背景。
Spring 提供的事务同步回调机制（
TransactionSynchronization，简称钩子）就是为了解决这种时序问题。核心思想是：把那些必须在事务成功后才执行的操作，注册为事务生命周期的回调，让框架在事务提交后再调用这些回调。常见的回调点包括事务开始、提交前、提交后、回滚时等。最常用的是提交后回调（afterCommit），它保证回调逻辑只在事务真正提交后运行。用这种方式，发消息这类副作用不会在事务未完成时触发，减少了数据和消息的不同步风险。
把这个思路用到具体场景，有两类常见用法。第一类是发消息：在写订单的事务中不直接发送消息，而是登记一个“提交后发送”的任务，等事务提交成功后再把消息推到MQ。第二类是搜索索引或外部系统同步：这些同步操作往往耗时，如果放在事务内会拉长事务时间，影响并发和吞吐。改成事务提交后再异步执行，不仅确保了数据一致性，还能缩短事务占用时间，提高性能。
实现细节上有几点必须注意。先说一个容易犯的错误：在没有真正激活事务上下文的方法里注册钩子，这种钩子永远不会被执行。缘由是事务同步管理器只有在激活事务时才会记录这些回调，如果你在一个普通方法里注册，没事务，注册了也白搭。另一种常见误区是在异步线程里注册回调。父线程有事务上下文，但子线程默认不会继承这个上下文，所以在子线程里注册钩子要么不生效，要么和预期的事务不一致。对策是，必须在有事务的同步方法里注册钩子，把实际的异步操作放到回调里去启动。
还有些复杂的边界场景需要留心。事务传播行为会影响回调执行的上下文：当用到REQUIRES_NEW时会新开一个事务，原来的事务被挂起；NOT_SUPPORTED会把事务挂起再执行。在这些传播策略下，注册的钩子可能和你预想的那个事务不是同一个，这会导致钩子不执行或在错误时刻执行。再有，afterCommit 的触发时机受事务管理器控制，不必定在提交那一刻“立刻”执行，有时会有延迟或顺序差异，尤其当同一事务内注册了多个钩子时，执行顺序需要约定清楚。
为了降低开销和复杂度，实践中有几条推荐做法：把多个需要在提交后执行的操作合并注册，减少钩子对象的创建；不要在钩子里再调用会开启新事务的方法并注册新的钩子，这会造成事务上下文混乱；把常用的“提交后操作”封装成工具类，项目里统一调用，减少重复代码；给钩子逻辑加上足够的监控和日志，遇到问题时能追踪到哪个事务、哪个回调在什么时间被执行或失败。使用 Spring Boot 3.x 时，可以借助
TransactionSynchronizationUtils 这类工具去简化注册回调的流程，使代码看起来更干净。
举两个具体例子，一个是消息发送，一个是搜索索引更新。消息发送场景按坏实现的流程是：插入订单；调用同步发送接口；方法返回；事务随后提交或回滚。正确做法是：插入订单；调用一个“注册提交后任务”的方法，把发送逻辑放到回调里；事务提交；回调触发，发送消息。这样即便事务回滚，回调也不会被执行。搜索索引的场景类似：直接在事务里同步更新 ES 会把事务拖得很长，影响性能。改成提交后把更新任务提交给线程池或异步服务，既保证了索引一致性，又把重负载的操作移出事务上下文。
在实战中，这些看似小的改动带来的效果很明显。我参与过一次生产事故排查：促销高峰期，订单量奇高，系统在写订单后立即发送扣减库存的消息，结果遇到并发写冲突时有事务回滚，但消息已经发出，导致库存被重复扣减，出现超卖。排查日志看到大量“事务同步未在完成后调用”的错误提示。团队把消息发送逻辑迁移到事务提交后的回调里，同时把对外同步的耗时部分改为异步处理。改造后，消息与数据的时序问题消失了，另外事务时间缩短，系统平均响应时间下降了大约40%。说实话，这招既不复杂也不惊艳，但在当时真起了大作用。
还有一些具体的注意点值得写清楚：如果需要在同一事务内注册多个钩子，尽量批量注册，避免频繁创建同步对象；不要在钩子逻辑里再去开启新的事务并注册新的回调，这样会让事务嵌套关系变得难以预测；对那些必须在提交后执行但又敏感于顺序的任务，显式控制执行顺序或把它们合并成一个有序队列；把钩子相关异常处理和重试机制设计好，防止提交后回调执行失败引起二次问题；在代码层面，把通用的提交后动作封装成工具或基类，让使用方直接调用，降低误用概率。
技术演进方面，Spring Boot 3.x 跟着 Spring 6 的步伐，把事务同步的支持做得更方便一些。列如提供了一些工具类去注册回调，细节实现更贴合现代项目的异步化需求，但底层原理没变：事务同步管理器依赖的是活跃的事务上下文。如果在没有事务的场景里盲目使用这些工具，还是会遇到“回调不触发”的问题。开发者要理解的是，注册钩子不是万能钥匙，它必须在合适的事务上下文里使用。
在排查这类问题时，日志和监控很重大。给事务回调加上足够的日志能在问题发生后迅速定位是哪条回调在什么时候被触发／未被触发；对失败的回调进行报警和追踪，能把后续补偿流程落到实处。对事务提交时长、回调执行耗时做指标统计，能够协助判断是否需要把某些操作继续下沉到异步任务中，或者合并优化。
总体上看，把副作用放到事务提交后执行，是一种“本地事务 + 提交后事件”的模式。它不依赖复杂的分布式事务协议，但能在绝大多数常见场景下解决数据与消息不同步的问题。对中小规模分布式系统，调整代码让副作用与事务状态对齐，一般比引入复杂的跨服务事务框架更经济实用。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
暂无评论...
