某次生产环境 TiDB (v6.5.0) 核心集群突发 P99 延迟暴增至 8s，QPS 断崖下跌。核心结论：业务对极少热点行高并发 UPDATE，引发 TiKV 悲观锁 RPC 风暴。大量等锁请求致 TiKV 死锁检测器 (Wait-For-Graph) 内存激增与 Scheduler Worker 线程池打满，演变为全局 RPC 拥塞。破局解法：开启 TiKV 内存悲观锁（In-Memory Pessimistic Lock）、调低锁超时触发快速失败，并强推业务层批量更新。
现场还原：P99 飙升与锁等待超时
排查过程中接警，某核心支付业务 TiDB 集群 QPS 从 8000 瞬间跌至 300，SQL 99线飙升到 8000ms。登录中控机，使用 tiup cluster display 确认各组件存活，但 Load Average 出现极度倾斜：部分 TiKV 节点 Load 飙升至 80+，而 TiDB Server 节点的 CPU 反而处于闲置状态。
查看 TiDB 日志，满屏的死锁与超时报错：
[WARN] [2006] ["Lock wait timeout exceeded; try restarting transaction"] [conn=482910]
[WARN] [endpoint.go:616] [error-response] [err="Deadlock found when trying to get lock; try restarting transaction"]
[INFO] [client.go:683] ["rpc error: code = DeadlineExceeded desc = context deadline exceeded"]
切到 Grafana 监控大盘，几个关键指标印证了猜想：
-
TiKV-Details -> Scheduler – commit：
AcquirePessimisticLock命令的 QPS 极高，且单个耗时超过 2s。 -
TiKV-Details -> Thread CPU：
Scheduler-worker线程池 CPU 使用率达到 100%，而raftstore线程负载平稳。 -
TiDB -> KV Errors：
Lock Resolve和Deadlock计数器呈指数级上升。
这典型的由于极度热点数据并发更新，导致的底层分布式锁拥塞惨案。
为什么高并发热点更新会打爆 TiKV 节点？
要理解这个故障，必须深入 TiDB 基于 Percolator 分布式事务模型的悲观锁实现。
原生的 Google Percolator 是一个标准的乐观事务模型（2PC：Prewrite + Commit），只在提交阶段进行冲突检测。但在高并发冲突场景下，乐观事务会导致大面积的 Write Conflict 报错和无意义的重试。为此，TiDB 从 v3.0 开始引入并默认开启了悲观锁。
在悲观锁模式下，TiDB 拦截了 MySQL 的 FOR UPDATE 或 DML 语句，在执行 Prewrite 之前，会提前向 TiKV 发起一次 AcquirePessimisticLock 的 RPC 请求。
当成千上万个并发请求去 UPDATE 同一行记录（例如扣减某个爆款商品的库存）时，灾难开始了：
-
单点 RPC 风暴：热点数据只存在于一个 Region，所有 TiDB 节点的
AcquirePessimisticLock请求全部涌向该 Region Leader 所在的单一 TiKV 节点。 -
死锁检测器 (Wait-For-Graph) 爆炸：TiKV 为了防止多事务相互等待引发死锁，在内存中维护了一个有向图（Wait-For-Graph）。当成千上万个事务在同一个 Key 上排队等锁时，这个图的节点数和边数急剧膨胀。死锁检测算法在遍历这张庞大的图时，消耗了海量的 CPU 周期，直接打满了
Scheduler-worker线程。 -
队列积压与雪崩：等锁的事务占用着资源不释放，后续的 gRPC 请求在 TiKV 端排队。最终超过客户端设定的 Context Timeout，引发
DeadlineExceeded报错。更致命的是，RPC 队列拥塞拖垮了同一个 TiKV 上的其他非热点请求，爆炸半径扩散，整个集群雪崩。
深度防御与参数调优实战
在分布式系统中，遇到这种极端热点，单纯增加硬件节点毫无意义（因为单行数据只会落在单一 Leader 上）。作为运维架构师，必须从“防御性编程”的角度在 DB 层做硬限制，同时开启底层优化特性。
1. 斩断长连接：调低锁超时机制（Fail-fast）
TiDB 默认的悲观锁等待超时时间（innodb_lock_wait_timeout）是 50 秒。在 QPS 几千的场景下，让请求挂起 50 秒等同于自杀。必须立刻修改为 Fail-fast 模式。
在 TiDB 侧全局调整（需要业务端捕获报错并处理）：
-- 将默认的 50s 修改为 3s，快速释放等待队列的资源
SET GLOBAL innodb_lock_wait_timeout = 3;
2. 核心大招：开启 TiKV 内存悲观锁 (In-Memory Pessimistic Lock)
在默认机制下，TiKV 获取悲观锁不仅要在内存排队，还要将锁信息通过 Raft 协议写入本地 RocksDB 并同步给 Follower，这个 I/O 路径极度沉重。 TiDB 在 v6.0 引入了内存悲观锁，在 v6.5 中成熟。它允许将悲观锁仅保留在 Region Leader 的内存中，不走 Raft 同步。即使 Leader 宕机，新 Leader 也能在读写前通过唤醒机制安全恢复。
编辑集群配置 (tiup cluster edit-config )，在 TiKV 模块中注入：
server_configs:
tikv:
pessimistic-txn.in-memory: true
# 强烈建议配合 pipelined 提交，减少网络往返延迟
pessimistic-txn.pipelined: true
执行 tiup cluster reload 滚动生效。开启后，AcquirePessimisticLock 的 P99 耗时从百毫秒级直接降至亚毫秒级，彻底缓解了 Scheduler Worker 的压力。
3. 业务层改造：禁止 DB 当 Redis 用
防御性运维只能保命，不能治本。排查发现业务在用 UPDATE counter SET val = val + 1 WHERE id = 1 做高频计数。
强推研发改写逻辑：
-
引入 Redis 做前端原子计数和防刷。
-
业务聚合请求，将单条记录的并发 Update 改为批量合并更新（Batching），或者改用分片插入（Insert on duplicate key update into multiple hash slots），最后再汇总。
常见问题
Q1：如何快速在雪崩现场定位是哪个 Key 引发了悲观锁争抢？ A：通过 TiDB 自带的系统表，直接查询当前正在等锁的事务和具体对应的 SQL：
SELECT * FROM information_schema.DATA_LOCK_WAITS;
SELECT * FROM information_schema.TIDB_TRX WHERE STATE = 'LockWaiting';
配合 TIDB_HOT_REGIONS 可以精准定位到是哪张表的哪个索引正在遭遇写热点。
Q2：既然高并发下悲观锁这么容易拥塞，我切回乐观锁（Optimistic）可以吗？
A：绝对不建议。乐观锁在遇到高并发热点时，会在最后的 Commit 阶段大面积爆出 Write Conflict 报错。虽然它不会引起 TiKV 侧的锁排队阻塞，但会导致客户端无休止地重试（如果开启了事务自动重试机制），白白浪费网络带宽和 TiDB CPU 计算力，最终一样会导致 QPS 下跌。正确的姿势是：保持悲观锁，开启 In-Memory 优化，并严格控制 innodb_lock_wait_timeout。
Q3：开启 In-Memory 悲观锁后，如果 Region Leader 发生网络隔离或宕机，会导致锁丢失引发脑裂吗？
A：不会。TiDB 的架构设计非常严谨。如果 Leader 宕机，锁虽然在内存中丢失，但发生 Leader 切换时，新的 Leader 会强制要求新的读写请求推进 ReadIndex 或产生新 epoch。此时旧事务在发起 Commit 阶段的 Prewrite 操作时，由于找不到原来的悲观锁，且 Region epoch 已经改变，事务会被直接中止（Abort），从而保证了分布式事务的严格一致性（Linearizability）。