TiKV 高内存场景下的写入优化策略分析

背景与问题现象

在分布式数据库TiKV的实际生产环境中，我们观察到一个典型的高内存使用场景引发的写入问题链式反应。当集群中某个节点磁盘空间不足时，会引发一系列连锁反应，最终导致整个集群写入能力下降。

具体表现为：当某个TiKV节点（如tikv-2）磁盘空间低于5%阈值时，节点会拒绝写入请求并返回"AlmostFull"错误。此时，其他健康节点（如tikv-0和tikv-1）由于无法向该节点同步raft日志，导致日志无法正常压缩，内存使用量持续增长。当内存达到高水位线后，这些原本健康的节点也开始拒绝写入请求，最终造成整个集群写入服务不可用。

问题根因分析

这个问题的核心在于TiKV当前的内存管理机制存在两个关键缺陷：

1. 故障传播机制不完善：单个节点的磁盘空间问题不应导致整个集群的写入能力丧失。健康节点在遇到同步障碍时，应该具备自我保护能力，而不是被动地让内存增长直至拒绝服务。

2. 内存回收策略不够积极：当内存使用量接近阈值时，系统应该优先尝试通过主动释放资源（如raft日志缓存）来维持服务，而不是直接拒绝请求。当前的实现缺乏这种积极的资源回收机制。

优化方案设计

针对上述问题，我们提出以下优化方向：

1. 主动内存回收机制

在内存使用量接近警戒线时，系统应该主动触发以下回收策略：

• 强制压缩raft日志，即使部分follower无法同步
• 主动释放entry cache等可重建的内存缓存
• 动态调整内存配额，优先保障核心写入路径

2. 故障隔离改进

实现更精细化的故障隔离策略：

• 区分磁盘空间问题和内存问题的影响范围
• 对于因follower问题导致的同步障碍，leader应继续服务可用的部分
• 实现部分写入可用性，而不是全有或全无的二元状态

3. 可观测性增强

改进监控指标和错误报告机制：

• 明确区分不同原因的"Server is busy"错误
• 暴露raft日志压缩受阻的详细指标
• 提供内存回收操作的相关metric

实现原理

优化的核心在于改写raft日志处理流程中的内存检查逻辑。当准备追加日志时：

1. 首先检查内存使用量
2. 如果接近阈值，尝试主动释放entry cache
3. 若释放后仍不足，再考虑拒绝请求
4. 记录内存回收操作的次数和效果

同时，对于因follower问题导致的日志压缩停滞，leader节点可以：

1. 标记不可用的follower
2. 继续为可用的follower服务
3. 定期重试与问题follower的连接

预期效果

实施这些优化后，系统将获得以下改进：

1. 降低故障爆炸半径：单个节点的磁盘问题不会扩散到整个集群
2. 提高系统韧性：内存压力下仍能维持基本服务能力
3. 提升运维效率：更清晰的监控指标便于快速定位问题根源

这种优化特别适用于磁盘空间不均衡的部署环境，能够显著提高TiKV集群的整体可用性和稳定性。