TiKV 存储引擎优化：改进清理机制降低扩缩容对尾部延迟的影响

背景介绍

在分布式数据库系统中，存储节点的扩缩容是常见的运维操作。作为 TiDB 的底层存储引擎，TiKV 需要确保在扩缩容过程中保持稳定的性能表现，特别是对尾部延迟（Tail Latency）的影响要尽可能小。尾部延迟指的是系统中最慢的那部分请求的延迟，对用户体验和系统稳定性至关重要。

问题分析

在 TiKV 当前的实现中，扩缩容操作会触发两个可能影响性能的关键行为：

1. 区域再平衡过程中的数据清理：当集群进行区域(Region)再平衡时，系统会清理不再属于当前节点的数据范围(stale ranges)。当前实现使用 ingest 操作来完成这一过程，这种操作虽然高效，但会对系统性能产生较大冲击。

2. 缩容节点的数据清理：在节点下线(scale-in)过程中，系统会主动清理即将离线节点的数据。实际上，这些数据在节点最终离线时会自动被清理，提前清理反而增加了不必要的开销。

这两种行为都会在扩缩容期间引入额外的 I/O 负载和 CPU 消耗，进而影响系统的尾部延迟表现。

优化方案

1. 区域再平衡清理机制优化

在区域再平衡过程中，我们将弃用 ingest 操作来清理 stale ranges。Ingest 操作虽然能快速完成数据清理，但其实现方式会：

• 产生大量的后台 I/O 操作
• 占用宝贵的磁盘带宽
• 与前台业务 I/O 产生竞争

替代方案将采用更温和的清理策略，通过后台任务逐步清理不再需要的数据范围，避免短时间内产生大量 I/O 压力。这种渐进式的清理方式虽然完成时间稍长，但对业务性能的影响显著降低。

2. 缩容节点数据清理优化

对于即将下线的节点，我们将不再主动清理其数据，而是：

• 标记节点为下线状态
• 停止向该节点写入新数据
• 等待节点自然下线时自动清理数据

这种优化基于以下观察：

• 下线节点的数据最终会被系统自动回收
• 主动清理不仅不必要，还会在关键时期增加系统负担
• 保留数据直到最后一刻可以避免重复的数据迁移操作

实现细节

在技术实现层面，这些优化需要：

1. 修改区域调度器逻辑：调整 Region Scheduler 的行为，使其在平衡区域时不触发 ingest 操作。

2. 改进节点下线流程：重构节点下线状态机，移除主动清理数据的步骤，同时确保系统能正确处理节点最终离线的各种情况。

3. 增强监控指标：添加专门的监控指标来跟踪清理操作的进度和资源消耗，便于运维人员评估优化效果。

预期收益

实施这些优化后，TiKV 集群在扩缩容期间将表现出：

• 更稳定的尾部延迟性能
• 更平滑的资源使用曲线
• 更短的性能恢复时间
• 更可预测的系统行为

对于用户而言，这意味着数据库在扩缩容期间能保持更稳定的响应时间，业务受到的影响将显著降低。

总结

通过优化 TiKV 在扩缩容期间的数据清理机制，我们能够在保证数据一致性的前提下，显著降低运维操作对系统性能的影响。这种优化特别适合对延迟敏感的生产环境，是提升 TiDB 整体可用性和用户体验的重要改进。