多线程并行读写场景下RocksDB低干扰全量清空所有键的实现方法

针对多线程并行读写、无需强一致清空分界、旧数据可临时读取、键无规则无固定范围阈值的场景，按干扰程度从低到高给出可落地方案：

最优方案：列族热切换（零业务侵入、极低干扰） #

这个方案完全规避了键范围匹配的问题，完美匹配「无明确清空分界、旧请求可正常读旧数据、新请求直接进空库」的容忍要求：

• 实现逻辑：
  • 收到清空请求后，立刻新建一个与旧列族配置完全一致的空列族（需要提前在数据库打开时配置允许新建列族，或启动时就预创建两个备用列族），这个操作只涉及元数据修改，耗时在微秒级，完全不阻塞现有线程
  • 用全局原子变量存储当前生效的列族句柄，清空请求触发后，直接原子替换这个句柄的指针，所有后续新读写都会默认走新的空列族
  • 旧列族不需要立刻清理，直接调用DropColumnFamily扔给后台处理：RocksDB会异步完成旧列族的所有SST文件回收、内存数据清理，全程不会阻塞新列族的任何读写操作；已经持有旧列族句柄的并行线程，依然可以正常读取旧数据，直到自己释放旧句柄
• 注意要点：
  • 新列族的比较器、压缩策略、布隆过滤器、块缓存配置必须和旧列族完全一致，避免行为偏差
  • 全局列族句柄必须用原子存储（比如std::atomic<rocksdb::ColumnFamilyHandle*>），不要用互斥锁保护，避免引入读写阻塞

次优方案：全范围DeleteRange（无需改列族架构） #

你之前对DeleteRange的「无固定上界」的顾虑是完全可以解决的：RocksDB的键空间是有序字节的全集合，不需要匹配业务键范围，直接用字节层面的全范围边界即可：

• 实现逻辑：
  • 对需要清空的列族直接调用DeleteRange接口，起始键传最小字节序列Slice("")（空串，是字节序下最小的键），结束键传最大字节序列Slice("\xff\xff\xff\xff")（只要保证这个值比所有业务键都大即可，不需要知道自己的最大业务键）
  • 这个操作只会写入一个范围删除标记，不会立刻遍历删除所有键，耗时在毫秒级，几乎不阻塞写线程；后续RocksDB在compaction过程中才会真正丢弃所有旧键值对
• 注意要点：
  • 如果有多个业务列族，需要对每个列族分别执行一次全范围DeleteRange
  • 范围删除标记对旧迭代器透明：清空流程启动前打开的迭代器依然能正常读到旧数据，新打开的迭代器会直接看到空库，完全符合容忍要求

特殊场景方案：序列号过滤逻辑清空（零磁盘操作） #

如果连写入DeleteRange标记的开销都要极致压缩，可以利用RocksDB的序列号机制实现逻辑清空：

• 实现逻辑：
  • 收到清空请求时，读取当前RocksDB的最大序列号作为清空阈值
  • 业务层读请求封装一层判断：如果读到的键值对序列号小于这个阈值，就直接跳过视为不存在
  • 后台异步慢慢遍历删除所有低于阈值的旧键值对，全程不影响业务读写
• 注意要点：这个方案需要业务层适配读逻辑（点查场景需要额外存键的序列号做判断，迭代器场景可以直接读取内置序列号），改动量比前两个方案大，只适合对延迟极度敏感的核心场景

避坑提示 #

• 不要用DeleteFile接口：该接口在7.0版本后已正式移除，且多线程环境下可能误删新写入的SST文件，存在一致性风险
• 不要用单键遍历逐个删除的方案：会产生海量写放大，严重拖慢compaction，对并行读写的干扰极大

内容的提问来源于stack exchange，提问作者Aviaconstructor