5.3 并发模型：单写多读与后台线程

5.3 并发模型：单写多读与后台线程

本节摘要：LevelDB 的并发模型不追求极致的无锁并行，而是刻意选择了"单写多读 + 后台压缩线程"的分工。本节拆解三大支柱的实现：互斥锁与条件变量如何序列化写入、原子指针如何让读者无锁并发、后台线程如何通过版本切换与前台协作。你会理解为什么这个看似简单的模型，反而是多数场景下最稳的选择。

本节目标

阅读完本节，你应当能够：

1. 说出 LevelDB 并发模型的三大支柱
2. 解释写入如何通过互斥锁 + 条件变量严格串行化
3. 说明读者为什么完全不需要写锁
4. 描述后台压缩线程与前台通过版本切换的协作机制

一、问题与直觉

多线程下最难的并发问题是"多写者竞争"：两个线程同时改同一个数据结构，怎么保证不互相踩脚？要么加复杂的锁，要么做无锁结构——两种都很难做对。

LevelDB 做了一个大胆的决定：干脆只允许一个写者。所有写入（Put、Delete、Write 批操作）在任何时刻最多一个线程执行。这从根上消除了多写者对 MemTable 和 WAL 的竞争，写入路径变得极其简单、确定、易同步。

那多核资源怎么办？LevelDB 的答案是把并发能力给"读"和"后台"：读可以任意多线程并发（看到版本保障的一致快照），昂贵的压缩扔给独立后台线程。这就是"单写多读 + 后台线程"的三支柱模型。

二、核心原理

支柱一：单线程写 —— 严格的写串行化

写入用一把专用互斥锁（writers_mutex_）和一个条件变量序列化。新写者先抢锁：没人写就当"当前写者"执行；有写者就进等待队列，在条件变量上等待。前一个写者完成后释放锁、signal 唤醒队列中的下一个。

这个设计保证了写操作的完全串行化，顺序与提交顺序一致——这是后面一切一致性保证的基础。

支柱二：多线程读 —— 无锁并发

读操作完全不需要 writers_mutex_。流程：获取当前 current_ 版本指针（原子操作），基于这个不可变版本的文件元数据查找，期间无任何全局锁阻塞写线程。

真正的读写同步点只有一个：MemTable 指针。写入修改活跃 MemTable，读取也要查它。LevelDB 用一个原子指针指向当前活跃 MemTable，切换时原子更新。MemTable 内部跳表对并发读安全（无锁读），写操作在单写者前提下串行，所以 MemTable 层面的读写并发是安全的。

支柱三：后台压缩线程 —— 异步协作

后台线程处理"脏活"：把 Immutable 落盘（Minor Compaction）、合并 SSTable（Major Compaction）。与前台协作的关键是版本系统：

1. 写线程检测到压缩条件，提交任务或设置标志，不亲自执行
2. 后台线程独立循环检查并执行压缩
3. 压缩完成生成新文件后，创建新 Version，原子切换 current_ 指针
4. 持有旧版本引用的读者不受影响，继续用旧文件
5. 无引用的旧文件最终被安全删除

几个精妙细节

双缓冲 MemTable：活跃表写满瞬间转 Immutable、原子换新活跃表——消除写入与压缩的相互等待，类似图形渲染的双缓冲。

压缩优先级：Immutable 落盘（Minor）优先级高于层级合并（Major），因为不尽快释放 Immutable 占的内存，会阻塞后续写入。

版本安装原子性：Version 切换（LogAndApply）不只是内存指针交换，还要把变更（VersionEdit）追加写进 MANIFEST。先写 Manifest 再切指针，保证崩溃恢复后状态一致。

三、工程实践要点

并发模型对照

适用场景判断

这个模型特别适合"读多写少"或"写入吞吐适中但读取并发要求高"的场景——作为存储引擎底层 KV、缓存系统的持久化层、消息队列元数据存储。

⚠️ 常见坑：以为单写者是"性能缺陷"而回避 LevelDB。实际上多数应用场景写入并非瓶颈，而单写者换来的简单性和确定性是巨大的工程资产。RocksDB 引入多线程压缩等增强，但核心的单写者思想依然延续——说明这个权衡在工业界被反复验证。

💡 关键直觉：把并发模型想成"单行收费站 + 多车道自由行 + 专职养护队"。车（写请求）必须排队过收费站（单写者），行人在旁边随便走（多读无锁），养护队（后台线程）夜里修路不影响白天通行。牺牲一点"同时过站"的吞吐，换来的是秩序井然、事故率极低。

SOURCE 独有事实

读写之间真正的同步点只有一个：MemTable 指针的原子切换。写操作执行到"修改全局状态"（切换 MemTable、安装新 Version）的极短瞬间，才与随后获取新状态的读存在由内存序（memory order）保障的同步。这意味着绝大多数时间里，读写是真正并行不悖的——这不是锁的功劳，而是"原子指针 + 不可变版本"设计的结果。另一个细节：若压缩未完成导致磁盘空间或文件数过多，LevelDB 会暂停或减缓前台写入，通过条件变量与状态标志实现压力下的自我调节。

四、深入展开：并发模型的工程判断

单写者的"简化红利"有多大

单写者模型初看像是性能让步，实际它带来的简化红利非常可观：写入路径上不再需要解决"两个线程同时改 MemTable"的竞态，WAL 追加也不用处理"日志交错"的问题，所有写入只需保证"串行顺序"即可。这大幅降低了正确性论证的难度，也让崩溃恢复的逻辑变得直白——重放日志的顺序就是写入顺序。

红利不止在实现，还在调优与排障：单写者意味着"写入吞吐的瓶颈只有一处"（写队列），出了问题只需检查这一个点；而多写者模型需要排查锁竞争、死锁、重排序等一堆问题。对大多数业务，多写者带来的吞吐提升远不如"单写者的可预测性"值钱。这也是为什么很多系统宁可牺牲一点并行度，也要保持写入路径的简单。

读者为什么能完全无锁

读者无锁依赖两个前提：一是 Version 是不可变对象（读者持有引用后内容不再变化）；二是 MemTable 指针切换是原子的（读者要么读到旧表、要么读到新表）。这两个前提合起来，保证了"读者无论何时启动，都拿到一个完整一致的快照"。

这种"不可变 + 原子指针"的模式，是比"读写锁"更优雅的并发方案：读写锁下读者和写者互斥（读时不能写），而这里读者完全不需要和写者同步。代价是需要接受"数据不能原地改"（用版本演进代替）。对存储引擎这种"写多、需要版本管理"的场景，这套模式几乎是最优解。理解它，你就理解了"无锁读"的真正来源——不是魔法，是精心设计的数据布局。

后台线程与前台的自适应博弈

LevelDB 的后台压缩线程不是"闷头干"，它与前台通过状态标志和条件变量互动：前台检测到压缩需求就设置标志、唤醒后台；后台完成压缩就更新版本、释放资源，并在必要时唤醒因写停顿等待的写线程。这个"前台提需求、后台干活、压力大时前台让路"的协作模式，是自适应系统的雏形。

它的精髓是"优先级和反馈"：Minor Compaction（释放内存）优先级高于 Major Compaction（整理磁盘），因为内存告急比磁盘乱更紧急；写停顿是"当后台跟不上时，让前台慢下来"的负反馈。这套反馈机制保证了系统在过载时不会崩溃，而是优雅地降速。理解了这个自适应逻辑，你就能解释很多"为什么 LevelDB 的延迟曲线会自己调整"的现象。

常见问题

问：单写者是不是意味着写入性能有上限？ 是，单写者模型的写入吞吐受限于"单个写线程能处理的速度"。但对绝大多数应用，这个上限远高于业务需求。真到不够用时（如 RocksDB 场景），才需要引入多写者或多线程压缩来突破。

问：为什么不用读写锁？ 读写锁下读者与写者互斥，读并发会被写阻塞。LevelDB 用"版本不可变 + 原子指针"让读者完全不受写影响，比读写锁更激进地并发化。

问：后台线程会拖慢前台吗？ 会共享磁盘带宽，极端情况下可能造成延迟尖峰。但它的 I/O 通常是顺序的、可控的，且不进 Block Cache 避免污染。监控 Compaction 的 I/O 占用是判断它是否影响前台的关键。

并发模型在全书中的定位

把并发模型放回全书坐标系：它是"版本管理（2.4 节）+ 快照（5.2 节）+ 单写者"三者的整合。版本管理提供"读者视角不动的保证"，快照提供"读者主动选时间点"的能力，单写者提供"写入顺序的确定性"——三者叠加，才有了"读并行、写串行、后台干活"的完整图景。

这也解释了为什么学并发模型时容易晕：它不是单一机制，而是多个机制的合力。学它的正确姿势是先分别吃透三个基础（版本、快照、写队列），再看它们如何咬合。如果你在前面章节的版本和快照部分有扎实理解，到这里会豁然开朗——原来所有线索在并发模型里汇合了。

并发模型的局限与替代方案

单写多读不是万能，它有两个显性局限：写入吞吐受单写者上限约束、压缩是单线程的（吞吐也有限）。针对这些局限，RocksDB 提供了多线程压缩、更细粒度的并发写分区等增强，但核心的"版本不可变 + 原子切换"思想被完整继承——这说明并发模型骨架的合理性经过了工业界的验证。

给你一个判断工具：当你评估一个 LSM 系引擎时，先看它的并发模型骨架（写是否串行、读是否无锁、后台如何协作），再看它在骨架上做了哪些增强。骨架决定"可理解性"，增强决定"极限性能"。对多数业务，骨架的可靠性比增强的性能更重要——这也是为什么单写多读至今仍是主流选择。

温故知新

• 要点一：并发模型三支柱 = 单线程写 + 多线程读 + 单后台压缩线程。
• 要点二：写入用互斥锁 + 条件变量严格串行化，顺序与提交顺序一致。
• 要点三：读者获取版本指针后完全无锁，同步点只剩 MemTable 指针原子切换。
• 要点四：后台线程通过创建新版本 + 原子切换 current_ 与前台协作。
• 要点五：Immutable 落盘优先级高于层级合并，防止内存积压阻塞写入。
• 要点六：模型适合读多写少场景，简单性与确定性是核心资产。

并发与一致性讲完了。下一章把这些理论兑现成调优手段——参数、键值设计、监控，一个都不能少。