TiKV中频繁删除表导致CDC增量扫描CPU使用率显著上升问题解析

问题背景

在TiKV分布式存储引擎中，当用户频繁执行表或分区的创建和删除操作时，可能会观察到CDC(变更数据捕获)增量扫描的CPU使用率异常升高。这种现象在TiKV的多个版本中都有出现，包括v6.5.x、v7.1.x、v7.5.x和v8.1.x系列。

问题现象

当系统中有大量表或分区的创建和删除操作时，CDC组件在进行增量数据扫描时会表现出异常高的CPU使用率。通过性能分析工具可以发现，这些CPU资源主要消耗在加载旧值(old value)的操作上。

根本原因分析

这个问题的根源在于TiKV内部的数据清理机制与CDC扫描机制的交互方式：

1. 数据清理机制：TiKV采用两种方式清理被删除表或分区的数据：

   • 通过DeleteFilesInRange操作
   • 通过Scan & Delete组合操作

2. RocksDB Tombstone问题：这种混合清理策略会在被删除的范围内留下连续的RocksDB Tombstone标记。这些标记可能被其他有效表数据的Region所覆盖。

3. CDC扫描行为：增量扫描会扫描整个Region而非仅观察的范围。当遇到连续的Tombstone标记时，RocksDB迭代器的Next操作会变得非常昂贵，导致扫描过程可能需要数小时才能完成。

技术细节

在底层实现上，TiKV的CDC组件为了优化性能，会使用RocksDBIter::Next而非RocksDBIter::Seek来避免昂贵的Seek操作。然而，当遇到大量连续的Tombstone标记时，Next操作反而会成为性能瓶颈：

• 每个Tombstone标记都需要被处理
• 连续的Tombstone导致Next操作需要遍历大量无效数据
• 这种遍历消耗大量CPU资源

解决方案

针对不同版本的TiKV，解决方案有所不同：

1. v7.1.x和v7.5.x版本：

   • 在加载旧值前先按观察范围过滤事件
   • 避免处理不必要的数据范围

2. v6.5.x版本：

   • 需要先回port相关基础优化
   • 然后应用相同的修复方案

修复效果

通过优化CDC的扫描策略，特别是改进了在存在大量Tombstone情况下的处理方式，这个问题得到了显著改善。修复后的版本包括：

• v7.1.6
• v7.5.5
• v8.1.3
• v8.5.0

对于v6.5.x版本，由于代码基础差异较大，未进行相应的修复。

最佳实践建议

对于使用TiKV CDC功能的用户，建议：

1. 避免在生产环境中频繁创建和删除大型表或分区
2. 定期维护数据库，合并碎片化的数据范围
3. 及时升级到已修复的版本
4. 监控CDC组件的CPU使用率，及时发现潜在问题

通过理解这一问题的本质和解决方案，用户可以更好地规划数据库操作模式，确保TiKV集群的稳定高效运行。