TiKV内存异常增长问题分析与解决方案

问题背景

在TiKV分布式事务处理过程中，我们发现了一个可能导致内存异常增长甚至引发OOM(内存溢出)的关键问题。该问题主要出现在高并发锁竞争场景下，特别是当死锁检测器(deadlock detector)的领导者(leader)与锁竞争发生的TiKV节点不在同一位置时。

问题现象

当大量事务同时竞争少量键的锁时，会出现以下情况：

1. 一个锁会阻塞许多其他事务，形成很长的锁等待队列
2. 锁竞争发生在死锁检测器领导者不在的TiKV节点上
3. 每次锁等待关系更新时，都需要通过RPC通知领导者节点

技术分析

问题的核心在于update_wait_for操作的实现方式。当N个悲观锁请求在队列中等待时，如果当前锁被释放并被另一个事务获取，所有等待的事务都需要更新它们的等待关系。

当前实现存在以下问题：

1. 每个等待关系变更都会生成单独的clean_up_wait_for和detect消息
2. 这些消息没有被批量处理
3. 当锁等待队列很长且锁获取/释放非常频繁时，会产生极高的消息发送速率

根本原因

问题的根本原因是消息发送通道的容量限制。当锁等待队列很长且锁状态变化频繁时，消息生成速度可能超过发送能力，导致消息在通道中堆积，最终引发内存持续增长直至OOM。

解决方案

虽然批量处理这些消息需要修改协议并增加复杂性，但这是解决该问题的必要步骤。可能的解决方案包括：

1. 实现消息批量发送机制
2. 优化锁等待关系更新的触发条件
3. 增加消息发送通道的容量和监控
4. 实现背压机制防止消息无限堆积

复现方法

为了验证该问题，可以通过以下步骤复现：

1. 创建至少2个TiKV节点的集群
2. 确保第一个region和测试表的region领导者位于不同TiKV节点
3. 运行高并发锁竞争测试程序

影响范围

该问题主要影响以下版本的TiKV：

• 7.1.x系列
• 7.5.x系列
• 8.1.x系列

总结

TiKV在高并发锁竞争场景下的内存异常增长问题是一个需要重视的系统性缺陷。通过分析，我们发现问题的核心在于死锁检测消息的处理机制不够高效。解决这一问题需要从协议层进行优化，实现消息的批量处理，同时加强系统的监控和自我保护能力。