大家好，我是墨哥（隐墨星辰）。今天的内容来源于两个线上问题，主要和大家聊聊为什么支付系统中基本只使用事务模板方法，而不使用声明式事务@Transaction注解，以及使用afterCommit()出现连接未按预期释放导致的性能问题。
1. 为什么不使用@Transaction注解
以前写管理平台的代码时，经常使用@Transaction注解，也就是所谓的声明式事务，简单而实用，但是在做支付后，基本上没有使用@Transaction，全部使用事务模板来做。主要有两个考虑：
1）事务的粒度控制不够灵活，容易出现长事务
@Transactional注解通常应用于方法级别，这意味着被注解的方法将作为一个整体运行在事务上下文中。在复杂的支付流程中，需要做各种运算处理，很多前置处理是不需要放在事务里面的。
而使用事务模板的话，就可以更精细的控制事务的开始和结束，以及更细粒度的错误处理逻辑。
@Transactional
public PayOrder process(PayRequest request) {validate(request);PayOrder payOrder = buildOrder(request);save(payOrder);// 其它处理otherProcess(payOrder);
}比如上面的校验，构建订单，其它处理都不需要放在事务中。
如果把@Transactional从process()中拿走，放到save()方法，也会面临另外的问题：otherProcess()依赖数据库保存成功后才能执行，如果保存失败，不能执行otherProcess()处理。全部考虑进来后，使用注解处理起来就很麻烦。
2）事务传播行为的复杂性
@Transactional注解支持不同的事务传播行为，虽然这提供了灵活性，但在实际应用中，错误的事务传播配置可能导致难以追踪的问题，如意外的事务提交或回滚。
而且经常有多层子函数调用，很容易子函数有一个耗时操作（比如RPC调用或请求外部应用），一方面可能出事长事务，另一方面还可能因为外调抛异步，导致事务回滚，数据库中都没有记录保存。
以前就在生产上碰到过类似的问题，因为在父方法使用了@Transactional注解，子函数抛出异常，去数据库找问题单据，竟然没有记录，翻代码一行行看，才发现问题。
2. afterCommit存在的问题及解法
有一次参与线上压测，在流量上去后，应用持续报获取数据库连接超时，排查很久才找到原因，问题非常经典，值得和大家聊聊。
无论在支付系统，还是电商系统，还是其它各种业务系统，都存在这样的需求：在一个事务中既保存多个数据库表，又要外发请求，且这个外发请求耗时很长。
比如：方法A保存数据库表A，方法B保存数据库表B，并且要外发给其它系统且耗时长，方法C要保存数据库表C。这三个方法需要在一个事务里面。
我见过三种方案：
方案一：不管三七二十一，就直接放在一个事务中。请求量不大时，看不出长事务的影响。
方案二：知道使用Spring提供的模板方法：TransactionSynchronizationAdapter.afterCommit()。外发请求耗时长过长时，在大并发下仍然有连接未能及时释放的问题。
方案三：自己实现事务模板方法，在Spring提交事务并释放连接后，再执行耗时长的外发。
第一种没什么好说的，下面介绍方案二和方案三，两者区别如下图所示：
在支付系统中，经常需要做一些流程编排，这些流程操作需要放在一个事务中，比如先保存主单据，再保存流水单据，然后外发银行请求扣款，有同学写的代码类似这样：
主方法伪代码（流程引擎入口）：
public void process(FlowContext context) {// 获取流程处理链List<FlowProcess> flows = fetchFlow(context);for (FlowProcess flow : flows) {// 使用事务模板dataSourceManager.getTransactionTemplate().execute(status -> {// 执行子流程flow.execute(context); // 更新主单信息context.getPayOrder().putJournal(context.getJournal());context.getPayOrder().transToNextStatus(context.getJournal().getTargetStatus());save(context.getPayOrder());return true;});}
}
其中一个外发银行子流程伪代码
public void execute(FlowContext context) {Journal journal = buildJournal(context);// 子函数里面保存了3张表的数据save(journal);TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {@Overridepublic void afterCommit() {// 事务提交后，再发送给外部银行gatewayService.sendToChannel(journal);}});
}预期是事务提交后再调用发给银行。
但是实际情况却是，Spring提交事务后，调用了afterCommit()，但是并没有释放连接，导致在外发银行的长达1000多毫秒的时间内，数据库连接一直在保持，而不是提交事务后马上归还了连接，加上线上服务器的连接数只分配了30个给每台应用。这就意味着最大并发也小于30。
通过查看AbstractPlatformTransactionManager.java，发现是先调用：riggerAfterCommit(status)，然后才清理并释放连接：cleanupAfterCompletion(status)。
private void processCommit(DefaultTransactionStatus status) throws TransactionException {try {// 其它代码省略... ...// Trigger afterCommit callbacks, with an exception thrown there// propagated to callers but the transaction still considered as committed.try {triggerAfterCommit(status);}// 其它代码省略... ...}finally {cleanupAfterCompletion(status);}}解决办法：自己创建一个事务模板，实现afterCommit()。
public class FlowTransactionTemplate { public static <R> R execute(FlowContext context, Supplier<R> callback) { TransactionTemplate template = context.getTransactionTemplate();Assert.notNull(template, "transactionTemplate cannot be null"); PlatformTransactionManager transactionManager = template.getTransactionManager();Assert.notNull(transactionManager, "transactionManager cannot be null"); boolean commit = false;try {TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition()); // Corrected "TranscationStatus" to "TransactionStatus"R result = null;try {result = callback.get();} catch (Exception e) {transactionManager.rollback(status); throw e;}transactionManager.commit(status);commit = true;return result;} finally {if (commit) {invokeAfterCommit(context);}}}private static void invokeAfterCommit(FlowContext context) {try {context.invokeAfterCommit();} catch (Exception e) {// 打印日志... ...}}
}
FlowContext加上事务提交后的执行的钩子方法，在钩子方法中实现一些长耗时工作：
public class FlowContext {// 其它代码不变... ...private List<AfterCommitHook> afterCommitHooks = new ArrayList<>();public void registerAfterCommitHook(AfterCommitHook hook) {afterCommitHooks.add(hook);}public void invokeAfterCommit() {try {for(AfterCommitHook hook : afterCommitHooks) {hook.afterCommit();}} catch (Exception e) {// 异常处理... ...} finally {// 钩子已执行完，清理掉afterCommitHooks.clear();}}public static abstract class AfterCommitHook {public abstract void afterCommit();}
}主流程修改为直接调用：FlowTranscationTemplate.execute。
public void process(FlowContext context) {context.setTransactionTemplate(dataSourceManager.getTransactionTemplate());List<FlowProcess> flows = fetchFlow(context);for (FlowProcess flow : flows) {// 把Spring模板方法修改自己的模板方法，其它不变FlowTransactionTemplate.execute(context, () -> {flow.execute(context);context.getPayOrder().putJournal(context.getJournal());context.getPayOrder().transToNextStatus(context.getJournal().getTargetStatus());save(context.getPayOrder());return true;});}
}
子流程修改为把afterCommit要做的事注册到流程上下文中：
public void execute(FlowContext context) {Journal journal = buildJournal(context);// 子函数里面保存了3张表的数据save(journal);// 把外发动作注册到流程上下文中的钩子方法中，// 而不是直接使用Spring原生的TransactionSynchronizationAdapter.afterCommit()// 其它保持不变context.registerAfterCommitHook(() -> {// 事务提交后发给银行gatewayService.sendToChannel(journal);});
}这样处理的优点有几个：
- 清晰的事务边界管理：通过显式控制事务的提交和回调执行，增加了代码的可控性。
- 资源使用优化：确保数据库连接在不需要时能够及时释放，提升了资源的使用效率。
- 灵活的后续操作扩展：允许注册多个回调，方便地添加事务提交后需要执行的操作，增强了代码的扩展性和复用性。
有个注意的点，就是确保invokeAfterCommit的稳健性，代码里是通过捕获异常打印日志，避免对其它操作有影响。
3. 扩展：长事务
长事务指的是在数据库管理和应用开发中，持续时间较长的事务处理过程。一般来说，在分布式应用中，每个服务器分配的连接数是有限的，比如每个服务器20个连接，这就要求我们必要尽量减少长事务，以便处理更多请求。
典型的方案有：
1）非事务类操作，就放在事务外面。比如前置处理，先请求下游获取资源，做各种校验，全部通过后，再启动事务。还有就是使用hook的方式，等事务提交后，再请求外部耗时的服务。
2）事务拆分。把一个长事务拆分为多个短事务。
3）异步处理。有点类似hook的方案。
4. 结束语
Spring事务管理提供了强大而灵活的机制来处理复杂的业务逻辑，但是每个特性和工具的使用都需要对其行为有深入的理解，而不能想当然。比如文中的afterCommit就是这样一个典型例子。
自定义事务模板的实践向我们展示了，虽然@Transcation注解很方便，但在一些特殊场景下，需要我们深入了解框架的工作原理并结合实际业务需求，既高效地利用Spring提供的工具，同时也规避潜在的坑点。
希望本文能够帮助读者更好地理解和应用Spring事务管理中的afterCommit钩子，以及如何在对资源或性能要求很严格的情况下，比如支付场景，如何定义自己的事务模板，帮助我们构建更健壮、更高效的应用。
这是《百图解码支付系统设计与实现》专栏系列文章中的第（30）篇。和墨哥（隐墨星辰）一起深入解码支付系统的方方面面。
欢迎转载。
Github（PDF文档全集，不定时更新）：GitHub - yinmo-sc/Decoding-Payment-System-Book: 百图解码支付系统设计与实现
精选
专栏地址：百图解码支付系统设计与实现
《百图解码支付系统设计与实现》专栏介绍
《百图解码支付系统设计与实现》专栏大纲及文章链接汇总（进度更新于2023.2.4）
领域相关（部分）：
支付行业黑话：支付系统必知术语一网打尽
跟着图走，学支付：在线支付系统设计的图解教程
图解收单平台：打造商户收款的高效之道
图解结算平台：准确高效给商户结款
图解收银台：支付系统承上启下的关键应用
图解支付引擎：资产流动的枢纽
图解渠道网关：不只是对接渠道的接口（一）
技术专题（部分）：
交易流水号的艺术：掌握支付系统的业务ID生成指南
揭密支付安全：为什么你的交易无法被篡改
金融密语：揭秘支付系统的加解密艺术
支付系统日志设计完全指南：构建高效监控和问题排查体系的关键基石
避免重复扣款：分布式支付系统的幂等性原理与实践
支付系统的心脏：简洁而精妙的状态机设计与核心代码实现
精确掌控并发：固定时间窗口算法在分布式环境下并发流量控制的设计与实现
精确掌控并发：滑动时间窗口算法在分布式环境下并发流量控制的设计与实现
