从区间锁到行锁：一次高并发写入死锁治理实战

资源账户写入链路长期存在 MySQL 死锁报警日常量级达到 99。虽然业务层依赖消息总线重试后多数请求可以成功但从数据库和链路治理角度看这类问题已经属于稳定存在的并发设计缺陷。本次治理聚焦一个典型场景同一 uid 并发发放多个新资源且对应账户记录尚未创建。原始实现中select ... for update 与 insert ... on duplicate key update 的组合在记录不存在时触发 gap lock / next-key lock导致后续插入互相等待最终形成死锁。优化目标不是简单去掉 for update而是在保留数据准确性的前提下缩小锁范围。最终方案分两步• 在正式加锁前先尝试插入一条数量为 0 的初始化记录将“锁区间”收敛为“锁行”。• 废弃 on duplicate key update 的写法改为显式 insert在唯一键冲突时回退到 update把高风险死锁降级为可控的并发竞争。图 1MySQL 死锁治理与并发优化概念封面一、问题背景与影响问题发生在资源账户表 user_resource_account 的写入路径中。业务动作很直接用户获得某个资源后需要把对应数量累加到账户表。线上主要出现以下并发场景• 同一个 uid• 极短时间内并发发放多个不同的 resourceId• 这些 (uid, resourceId) 记录在账户表中尚不存在在这种情况下应用日志和数据库侧会频繁出现死锁报警。由于上层 bus 具备重试机制最终业务结果大多可恢复因此问题一度没有直接暴露为用户故障。但从工程视角看这类死锁仍然需要治理原因主要有 3 点• 数据库需要反复做无效锁竞争增加了事务回滚和重试成本。• 消息链路承担了额外的消费抖动放大了热点用户或热点活动下的链路不稳定性。• 高频死锁会稀释异常告警的信噪比不利于真正高风险故障的识别。因此这次治理的目标不是“让重试成功率更高”而是把这条写入路径从“依赖重试兜底”改造成“并发行为本身更稳定”。二、现网实现与问题入口原始实现的核心 SQL 如下SQLselect *from user_resource_accountwhere uid #{uid} and resource_id #{resourceId}for update;SQLinsert into user_resource_accountset uid #{uid},resource_id #{resourceId},free_num #{num},total_num #{num}on duplicate key updatefree_num free_num #{num},total_num total_num #{num};如果只看业务语义这套实现很自然• 通过 select ... for update 保证并发安全。• 如果账户记录不存在则通过 insert 建立新记录。• 如果多个线程并发命中同一唯一键则依赖 on duplicate key update 完成累加。问题在于这段逻辑在“记录已经存在”的情况下通常没有问题而真正的高风险点恰恰出现在“记录不存在”的分支。三、死锁形成机制3.1 关键事实记录不存在时锁的不一定是空这次问题的关键认知是select ... for update 在目标记录不存在时并不是“什么都不锁”。在 InnoDB 的可重复读锁模型下如果查询命中的是唯一索引上的一个不存在的键值数据库可能会在相邻索引区间上加 gap lock 或 next-key lock以阻止其他事务在该区间插入数据。这意味着业务虽然只是“查不到一条记录”但数据库实际保护的是“一段索引范围”。3.2 死锁序列还原假设同一个用户 U 并发发放两个新资源 ResourceA 和 ResourceB且两条账户记录都不存在。一个可行的死锁序列如下• 事务 T1 执行 select ... where uid U and resource_id ResourceA for update• 事务 T2 执行 select ... where uid U and resource_id ResourceB for update• 由于两条记录都不存在T1 与 T2 分别在相邻索引区间上持有 gap lock / next-key lock• T1 继续执行 insert ResourceA• T2 继续执行 insert ResourceB• 插入阶段需要申请插入意向锁而该锁与对方之前持有的区间锁冲突• 最终形成循环等待MySQL 选择回滚其中一个事务图 2死锁形成与优化后的概念对比示意图3.3 为什么不是简单的唯一键冲突如果是两个线程并发写同一个 (uid, resourceId)更常见的现象通常是• 一个线程插入成功• 另一个线程抛出 DuplicateKeyException而本次线上实际出现的是 Deadlock found when trying to get lock。这说明事务失败点发生在“拿锁阶段”而不是“唯一键校验阶段”。因此问题本质不是主键或唯一键冲突而是锁顺序与锁粒度导致的互相等待。四、方案设计约束在确定优化方案前先明确几个边界条件。第一不能简单取消 for update。 这条链路对应的是资源账户数量后续需要支持账务核对和问题追踪因此写入过程仍然需要明确的并发控制。第二不能只依赖重试来消化问题。 重试解决的是结果可恢复不解决数据库层的高频锁竞争。第三优化目标不是“完全无竞争”而是把冲突从死锁互等收敛成系统能够稳定处理的形式。基于这些约束优化方向应当是在保留数据准确性的前提下缩小锁范围、简化写入路径、降低锁竞争的不确定性。五、优化方案5.1 方案一预创建 0 值记录在正式执行 for update 之前先尝试插入一条数量为 0 的账户记录对于新资源相关的过期记录也执行同样的预创建逻辑。这一步的价值在于把原来的“查不到记录”转化为“查得到记录”。后续再执行 for update 时锁住的就是目标行本身而不是索引区间。从锁行为上看这个改动的核心收益是• 原先的热点竞争发生在“索引区间”• 改造后主要竞争收敛到“真实存在的记录”也就是说这一步并没有消除并发而是显著缩小了锁影响范围。5.2 方案二显式 insert冲突后回退 update第二个改动是废弃 on duplicate key update改成更明确的写入路径JAVAprivate ResourceUserAccount addResourceAccount(Long uid, Resource Resource, int num, Date currentTime) {try {ResourceUserAccountMapper.insertOldData(uid, Resource.getPlatform(), Resource.getresourceId(), num, currentTime);} catch (DuplicateKeyException e) {log.warn(ResourceUserAccount duplicate key on insert, fallback to update. uid:{}, resourceId:{},uid, Resource.getresourceId(), e);ResourceUserAccountMapper.updateNum(uid, Resource.getresourceId(), num, currentTime);} catch (Exception e) {log.error(addResourceAccountException, e);throw e;}return ResourceUserAccountMapper.getUserResourceInfo(uid, Resource.getresourceId());}采用这条路径后并发场景会变得更可解释• 如果记录尚未建立则插入成功。• 如果其他线程已经抢先插入则本线程拿到 DuplicateKeyException。• 捕获异常后再执行 update 完成数量累加。这相当于把原来耦合在一条 SQL 里的“插入或更新”语义拆开使冲突路径更透明也更便于监控和告警分类。六、方案收益与边界6.1 机制层面的收益这次改造带来的收益主要体现在机制上而不是语法层面• 把锁从区间锁收敛为行锁降低了“记录不存在”分支的锁放大问题。• 把异常从死锁回滚收敛为唯一键竞争降低了事务互等的复杂度。• 把写入路径从“数据库自行决定插入或更新”改成“应用明确控制回退逻辑”提升了问题定位与可观测性。6.2 边界与残余风险这个方案并不意味着该链路从此不会再有锁竞争。仍然需要注意几个边界• 如果后续在同一事务中继续引入更多表、更多索引或更复杂的锁顺序仍然可能产生新的死锁路径。• 如果同一 uid 的热点写入强度持续升高虽然死锁概率下降但行级竞争和重试成本仍然可能成为性能瓶颈。• 如果初始化逻辑和正式写入逻辑之间缺乏统一约束可能引入新的数据一致性分支。因此这个方案的正确解读不是“彻底消灭冲突”而是“把原来最难处理的冲突形态降级为更可控的竞争形态”。七、可复用经验结合这次治理可以沉淀出几条更通用的经验• 在高并发场景下最危险的往往不是更新已有记录而是并发创建原本不存在的记录。• select ... for update 不能只从业务语义理解还必须结合 InnoDB 的锁语义理解尤其要关注不存在记录时的区间锁行为。• on duplicate key update 适合简化普通写入逻辑但在热点写入、强一致或复杂事务场景下需要评估其锁行为是否可接受。• 处理并发问题时与其追求零冲突不如优先把冲突变成可预测、可恢复、可观测的形态。八、总结这次资源账户死锁治理本质上不是一次 SQL 改写而是一次对锁模型的纠偏。业务层看到的是“账户不存在先查再插”数据库层看到的却可能是“多个事务正在竞争同一段索引区间”。只要这个认知偏差不被修正类似的问题就会在库存、额度、账户、券包等场景反复出现。这次优化的价值归根到底是两点• 让锁落在真实存在的记录上而不是落在不确定的区间上。• 让冲突以应用能够明确处理的方式暴露出来而不是以事务互锁的方式随机失败。这也是后续处理类似并发写入问题时一个值得优先复用的思路。