标签：#RocksDB #Database #LSM-Tree #Architecture #Backend #Interview
📉 前言：B+ 树跌落神坛？
在传统机械硬盘时代，MySQL 的 InnoDB 选择了B+ 树。它对读非常友好，但面对海量并发写入时，随机 I/O 会导致磁盘磁头疯狂跳动，性能急剧下降。
而在 SSD 普及和云原生时代，RocksDB选择了LSM-Tree (Log-Structured Merge Tree)。
它的核心哲学是：利用磁盘的顺序写性能，放弃部分读性能。
简单说：不管你是插入、修改还是删除，我全部视为“追加写入日志”。
🏗️ 一、 核心架构：内存与磁盘的接力赛
RocksDB 的架构可以看作是数据从“内存”流向“磁盘”的多级瀑布。
组件全景图 (Mermaid):
- MemTable: 内存中的数据结构（通常是SkipList 跳表），支持高性能的并发写入。
- Immutable MemTable: 当 MemTable 写满后，会变成“只读”状态，等待后台线程刷盘。
- WAL (Write Ahead Log): 为了防止断电数据丢失，写入内存前先顺序追加写日志。
- SSTable (Sorted String Table): 磁盘上的数据文件，内部 Key 是有序的。
🚀 二、 写路径 (Write Path)：速度的极致
RocksDB 的写操作是出了名的快，因为它把所有的随机写都变成了顺序写。
写入流程：
- 写 WAL：追加日志，磁盘顺序写，极快。
- 写 MemTable：插入内存跳表，，极快。
- 结束：告诉客户端“写完了”。
注意：这里没有磁盘随机 I/O！哪怕是DELETE操作，在 RocksDB 眼里也是写入一条类型为Tombstone(墓碑) 的标记数据。真正的数据删除发生在后续的 Compaction 阶段。
🐢 三、 读路径 (Read Path)：为了速度还的债
由于数据分层存储，读操作可能需要像“翻箱倒柜”一样查找数据。
读取流程 (Mermaid):
性能瓶颈：
- L0 层最慢：L0 层的文件是直接由内存 Flush 下来的，里面的 Key 范围是互相重叠的。如果我有 4 个 L0 文件，我可能需要把这 4 个文件全读一遍才能确定 Key 是否存在。
- L1+ 层较快：L1 及更底层的 Key 是全局有序且不重叠的，可以通过二分查找快速定位。
优化神器：Bloom Filter (布隆过滤器)
为了避免无效的磁盘 I/O，RocksDB 为每个 SSTable 配备了布隆过滤器。它能以极快的速度告诉你：“这个 Key 绝对不在这个文件里”，从而跳过大量不必要的读取。
🧹 四、 Compaction (压缩)：整理房间的艺术
随着数据越写越多，L0 层文件会堆积，读取性能会下降。这时需要Compaction。
Leveled Compaction (分层压缩) 机制：
- L0 -> L1：当 L0 文件数量达到阈值（如 4 个），触发合并。系统会把 L0 的文件和 L1 中有重叠的文件读出来，进行归并排序，生成新的 L1 文件。
- L1 -> L2：当 L1 大小达到阈值（如 256MB），会选出一个文件，和 L2 中重叠的文件合并。
- 墓碑清理：在这个过程中，如果你写入了
DELETE标记，旧数据和标记会在合并时“同归于尽”，真正释放磁盘空间。
写放大 (Write Amplification)：
这就是 LSM-Tree 的代价。一条数据虽然写入时很快，但在生命周期中，可能会被 Compaction 机制反复读取、合并、写入磁盘多达几十次。这也是 RocksDB 调优的核心痛点。
🎯 总结：面试必问知识点
- 为什么 RocksDB 写得快？
- 利用 WAL 顺序写 + 内存 SkipList，无随机 I/O。
- 为什么 RocksDB 读得慢？怎么优化？
- 需要多层查找。
- 优化：使用Bloom Filter减少磁盘访问；使用Block Cache缓存热点数据。
- Level 0 和 Level 1 的区别？
- L0：Key 范围重叠（读慢），由 MemTable 直接 Flush 而来。
- L1+：Key 全局有序且不重叠（读快），由 Compaction 归并而来。
Next Step:
下载RocksJava依赖，在你的 Spring Boot 项目中集成 RocksDB。尝试调整write_buffer_size(MemTable 大小) 和max_background_compactions参数，观察写入 100 万条数据时的 IOPS 变化。你会对“参数调优”有全新的认识。
