TiKV项目中移除Compaction Filter的写入停顿检查机制

在TiKV存储引擎的演进过程中，RocksDB作为其底层存储引擎发挥着关键作用。近期TiKV团队决定移除Compaction Filter中的写入停顿检查机制，这一变更反映了系统架构的演进和流量控制机制的成熟。

背景与历史

Compaction Filter是RocksDB提供的一个重要特性，它允许在压缩过程中对键值对进行过滤或修改。在早期版本的TiKV中，为了防止资源浪费，开发团队在Compaction Filter中加入了写入停顿检查机制。这一机制的主要目的是在系统负载过高时避免不必要的资源消耗。

写入停顿(Write Stall)是RocksDB的一种自我保护机制，当系统遇到后台工作积压(如压缩跟不上写入速度)时，会主动限制写入速率以防止情况恶化。早期的TiKV版本依赖这一机制来控制系统负载。

架构演进

随着TiKV的发展，系统引入了更完善的流量控制(Flow Control)机制。这一机制在更高层次上协调了各个组件的工作负载，使得RocksDB层面的写入停顿变得不再必要。实际上，在新版本的TiKV中，RocksDB的写入停顿功能默认是被禁用的。

流量控制机制相比写入停顿有几个显著优势：

1. 更全局的视角：流量控制可以协调整个TiKV实例而不仅仅是单个RocksDB实例
2. 更精细的调控：可以根据不同优先级和工作类型进行差异化控制
3. 更及时的响应：避免了从底层存储层到上层应用层的延迟反馈

移除决策的原因

维护Compaction Filter中的写入停顿检查机制逐渐显现出以下问题：

1. 维护成本增加：随着代码演进，这一机制需要不断适配新的架构变化
2. 收益递减：在流量控制机制成熟后，其实际效果有限
3. 潜在干扰：可能与新的流量控制机制产生不必要的交互

经过评估，团队认为这一机制当前的维护成本已经超过了它带来的收益，因此决定将其移除。这一变更也符合TiKV架构向更高级别资源管理发展的趋势。

影响与展望

这一变更对用户的影响微乎其微，因为系统已经通过流量控制机制提供了更好的负载管理能力。从架构角度看，这代表了TiKV在资源管理方面的一个成熟标志——从依赖底层存储引擎的机制转向更智能、更全局的资源调度。

未来，TiKV可能会继续优化其资源管理策略，在保持高性能的同时，提供更稳定的服务质量。这种架构演进也体现了分布式存储系统从简单到复杂、从局部优化到全局协调的典型发展路径。