Apache Kvrocks 2.10.0版本中RocksDB Blob文件泄漏问题分析

问题背景

Apache Kvrocks作为一款高性能的Redis兼容存储系统，在2.10.0版本中升级了底层依赖的RocksDB存储引擎至9.6.1版本。这一升级引入了一个严重问题：当启用rocksdb.enable_blob_files配置项并持续写入带TTL的数据时，系统会出现磁盘空间耗尽的情况。

问题现象

用户在实际部署中发现，随着系统持续运行，磁盘使用率会不断攀升直至耗尽。通过检查系统状态发现：

1. 大量被标记为"deleted"状态的blob文件仍被Kvrocks进程保持打开
2. 这些文件虽然已被逻辑删除，但并未释放物理存储空间
3. 重启服务后，这些被占用的空间才真正释放

技术分析

Blob文件机制

RocksDB的Blob文件是8.0版本引入的重要特性，它将大值数据与LSM树分离存储，主要优势包括：

• 减少LSM树的压缩放大效应
• 提高大值场景下的写入性能
• 优化存储空间利用率

问题根源

经过社区调查，这个问题与RocksDB 9.4.0版本引入的一个变更有关。具体表现为：

1. 当TTL数据过期时，对应的Blob文件应该被清理
2. 但文件描述符未被正确关闭，导致系统仍占用这些文件
3. 随着时间推移，积累的"僵尸"文件会耗尽所有可用空间

解决方案

Kvrocks社区经过讨论确定了以下解决方案路径：

短期方案

在即将发布的2.10.1版本中：

1. 将RocksDB回退至9.3.1版本
   • 该版本尚未引入此问题
   • 相比完全回退到8.x系列，对系统影响更小
2. 确保向前兼容性，用户无需重建数据库

长期方案

考虑在后续版本中：

1. 暴露uncache_aggressiveness配置参数
2. 让用户能够更主动地控制缓存回收行为
3. 在升级到修复此问题的RocksDB版本后重新评估

用户建议

对于当前遇到此问题的用户，建议：

1. 监控磁盘使用情况，设置预警阈值
2. 考虑临时增加磁盘容量
3. 准备在2.10.1发布后尽快升级
4. 如问题紧急，可定期重启服务释放空间（非生产环境推荐）

技术启示

这个案例展示了存储系统升级中可能遇到的隐蔽问题：

1. 底层引擎的变更可能带来意想不到的副作用
2. 资源泄漏类问题往往需要长时间运行才会显现
3. 完善的监控体系对及时发现此类问题至关重要
4. 社区协作在问题定位和解决中发挥关键作用

Kvrocks社区对此问题的快速响应和处理，体现了开源项目在质量保障方面的成熟流程和负责任态度。