事务里夹了一段 3 秒远程调用：连接池没打满却整体雪崩的事务边界复盘

栈：Spring Boot 3.2.4、JDK 17、HikariCP 5.1.0、MySQL 8.0.32；一个订单服务，4 实例、每实例 8C16G，连接池 maximumPoolSize=50。

一、现象与背景：连接池「没满」，接口却集体超时

先给数字。一次下单链路压测，目标 1200 QPS，压到 800 QPS 时开始劣化：

下单接口 P50 稳定 45ms，但 P99 从 45ms 一路爬到 11s，最后大量请求直接打穿 30s 网关超时；
HikariCP 监控里 active 长期在 30~40 之间徘徊，idle 只剩 10~20，从未到 50——按经验这不算「连接池打满」；
show engine innodb status 里能看到 SEMAPHORES 的行锁等待在涨，但 max_connections（4000）远没到；
最反直觉的一条：下游风控 RPC 的 P99 平时 120ms，压测时飙到 3.2s，而且它和下单接口在同一个进程里被同一个方法调用。

一开始全往「连接池太小 / 数据库慢 / 锁竞争」上找，把 maximumPoolSize 从 50 加到 120、调了 innodb_purge_threads，全都没救回来。最后顺着「哪个方法既持有 DB 连接、又调了远程」这条线，才挖到真正的根因。

二、根因：远程调用被「夹」进了事务边界

问题出在下单主流程这个方法上（简化）：

@Transactional(propagation = Propagation.REQUIRED)
public OrderResult createOrder(OrderReq req) {
    // 1. 查库存、扣库存 —— 这里 DB 连接被借出、行锁被持有
    stockDao.deduct(req.getSkuId(), req.getQty());
    // 2. 同步调风控（下游偶发 3.2s）
    RiskResult risk = riskClient.check(req);          // ← 阻塞 3.2s
    if (risk.isRejected()) { throw new BizException("risk"); }
    // 3. 落订单
    orderDao.save(buildOrder(req, risk));
    return ok();
}

机制拆开讲，为什么它会「雪崩」：

连接的持有期 = 事务的存活期，不是 SQL 的执行期。 HikariCP 在方法第一次触到 DAO 时借出连接（stockDao.deduct），直到方法返回、@Transactional 的 commit/rollback 完成才归还。中间那 3.2s 的 riskClient.check，连接全程占着不还，行锁（deduct 上的排他锁）也全程不释放。
REQUIRED 传播让内层方法复用外层事务。 有人把 check 拆到另一个 @Transactional 方法里，但只要传播级别还是 REQUIRED，它不会开新事务，而是继续用外层那个已经持有连接和行锁的事务，等于白拆。
放大效应 = 慢下游 × 并发。 单条 3.2s 看着不吓人，可 800 QPS 意味着同一时刻有几十上百个请求都卡在「持有连接 + 持有行锁 + 等风控」的状态。行锁持有时间从毫秒级被拉到秒级 → InnoDB 行锁排队 → 排队的人又各自占着连接 → 连接池被「慢事务」拖住。这就是为什么 active 没到 50 也会「拿不到快连接」：池里不是没连接，是连接都被慢事务「锁」住了，新请求要么等连接、要么等行锁。

一句话根因：不是连接池不够大、不是数据库慢，是事务边界里夹了一段本不该在事务内的同步远程调用，把「持锁时间」从毫秒放大到了秒。

三、具体做法：把远程调用请出事务边界

做法 A（首选）：远程调用前置到事务外，事务里只做 DB 操作。

public OrderResult createOrder(OrderReq req) {
    // 事务外：先调风控（阻塞 3.2s 不再占用任何 DB 连接 / 行锁）
    RiskResult risk = riskClient.check(req);
    if (risk.isRejected()) { throw new BizException("risk"); }
    // 事务内：只做「扣库存 + 落单」，持锁时间回到毫秒级
    return txCreateOrder(req, risk);
}

@Transactional(propagation = Propagation.REQUIRED, timeout = 3)
public OrderResult txCreateOrder(OrderReq req, RiskResult risk) {
    stockDao.deduct(req.getSkuId(), req.getQty());
    orderDao.save(buildOrder(req, risk));
    return ok();
}

改完压测：800 QPS 下 P99 从 11s 回落到 180ms，active 稳定在 12~18，行锁等待消失。

做法 B：给事务加硬超时，防止任何「夹心」把事务拖成秒级。 @Transactional(timeout = 3)（单位秒）。注意这是数据库事务的超时，它管不到事务里那段 RPC，所以只能作为兜底、不能替代做法 A。

做法 C：必须同进程内做时，用 REQUIRES_NEW 把「慢」和「快」隔离开。

@Transactional(propagation = Propagation.REQUIRES_NEW)
public RiskResult checkInNewTx(OrderReq req) { ... }

但这里有个自调用陷阱：同一个 Bean 里 this.checkInNewTx(...) 不走 Spring 代理，REQUIRES_NEW 不生效，仍是外层事务。必须拆成两个 Bean、或注入自身代理 / 用 AopContext.currentProxy()。

四、踩过的坑（反直觉的地方）

active 没到 maximumPoolSize ≠ 健康。 只要慢事务在持续占用，「还剩一点 idle」也会让 P99 爆炸。看监控别只盯 active 顶没顶到上限。
@Transactional(timeout) 管不到事务内的 RPC。 很多人以为设了 timeout 就能兜住慢调用，实际上它约束的是 DB 事务，远程调用那 3.2s 它一点都感知不到。
REQUIRED 拆方法 = 假拆。 默认传播级别会复用外层事务，「把慢调用挪到另一个带 @Transactional 的方法里」如果还在同一事务里，等于没拆。
REQUIRES_NEW 的 rollback-only 陷阱。 若内层新事务抛异常，会把外层事务标记为 rollback-only，外层 catch 住后 commit 时会抛 UnexpectedRollbackException。用隔离新事务时，要么让内层异常向上抛，要么在 catch 后只记录不 commit。
自调用让一切 AOP 失效。 拆 Bean / 代理是前提，否则传播级别、超时、异常回滚全都不生效。

五、结论与可复用清单

核心结论：事务边界里只能放「快」的本地 DB 操作；任何同步远程调用（RPC / HTTP / 第三方）都应前置到事务外，或显式拆成独立事务。 连接池大小、purge_threads 这些参数救不了「被慢调用撑大的事务」，因为瓶颈在持锁时长，不在资源数量。

可复用清单（压测前自查）：

[ ] 全局搜 @Transactional，确认方法体内没有任何 riskClient / httpClient / 第三方 SDK 同步调用；
[ ] 事务方法统一加 timeout（建议 2~3s）做兜底，但别依赖它；
[ ] 需要「慢操作 + DB 事务」共存时，慢操作放事务外，或显式 REQUIRES_NEW 且拆 Bean；
[ ] 监控同时看 activeConnections 与 openTransactions：两者差值大 = 有连接被「夹心事务」占着；
[ ] 压测时对齐「下游 RPC P99」与「本服务 P99」的拐点，二者同时劣化基本可断定是事务内夹了远程调用；
[ ] 代码评审加一条硬规则：@Transactional 方法内禁止出现阻塞型远程调用（CR 关键词告警）。

一句话记忆：慢调用放事务里，等于把连接和行锁一起抵押给了下游的 P99。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。