5.1 原子性：WriteBatch 与日志先行

5.1 原子性：WriteBatch 与日志先行

本节摘要：原子性保证"一批操作要么全部生效，要么全部不生效"。LevelDB 通过两个经典范式的组合实现它：预写式日志（WAL）确保持久性，批量提交（WriteBatch）确保整体性。本节拆解 WriteBatch 的编码格式、写入流程，以及为什么"整批连续写日志 + 共享序列号"能同时给出原子性与性能。

读前必看

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

1. 解释"日志先行"为什么是原子性与持久性的基石
2. 画出 WriteBatch 从提交到落盘的关键路径
3. 说清 WriteBatch 的编码格式与其自包含性
4. 识别 WriteBatch 原子性的边界（不覆盖读-改-写）

一、问题与直觉

先设想一个银行转账：从账户 A 扣 100，往账户 B 加 100。如果两个操作不是原子的，系统可能在扣完 A 后崩溃——金额凭空消失，数据库进入一个永远无法自愈的矛盾状态。

LevelDB 的场景没有 SQL 事务那么复杂，但同样需要"一批操作要么全成、要么全不成"。比如维护一个倒排索引：删除一个文档，要从多个关键词的倒排列表里同时移除文档 ID，这些操作必须原子完成，否则索引就损坏了。

答案落在一句古老而强大的原则上：先写日志，再改内存。以及一个简洁的载体：WriteBatch。

二、核心原理

日志先行：可靠性的基石

WAL 的原则很简单：在内存表（MemTable）被实际修改之前，先把"这次修改是什么"追加写进一个只能追加的持久化日志文件。WAL 像高保真的飞行记录仪，完整记录导致数据库到达当前状态的所有操作指令。

如果系统在改内存时崩溃，重启后重放 WAL 就能重建崩溃前的内存状态。WAL 还把"随机写分散数据页"变成了"顺序写追加日志"，这在磁盘 I/O 层面本身就是巨大优化。

批量提交：WriteBatch 的原子单元

单个键值对写入很容易原子，但多个相关操作呢？如果分开独立写 WAL，系统可能写了一半就崩溃。解法是把多个操作捆绑成一个不可分割的单元——WriteBatch。用户把任意数量的 Put/Delete 放进一个 WriteBatch，整体提交，系统保证批次内所有操作要么全部对后续读取可见，要么全部不可见。

关键路径：整批写日志 + 共享序列号

关键在：整个 WriteBatch 的编码内容作为一个连续字节序列，原子性地写入 WAL。一次 write 调用在文件系统层面保证数据完整性——要么全部写入，要么完全不出现。这为整批的持久化奠定了原子基础。

随后按 sync 选项决定是否 fsync。若 sync=true，数据从页缓存刷入物理磁盘，持久性最强。之后 WriteBatch 中的操作才逐一应用到 MemTable。由于 WAL 已持久化，即使应用 MemTable 时崩溃，重启后重放日志也能完整恢复整批。

WriteBatch 的编码格式

WriteBatch 是内存缓冲区，编码为一段连续自描述字节序列：

• 头部：[序列号 8 字节][计数 4 字节]
• 每条记录：[操作类型 1 字节][键长度变长编码][键内容][值长度（仅 Put）][值内容（仅 Put）]

这种紧凑自包含的编码让整个 WriteBatch 能作为一条完整"消息"被原子处理，恢复时也能完整读取解析。

原子性的全局视图：版本切换

写入最终要反映到读者视图。每次 Compaction 或 Flush 生成新文件，都会创建新 Version 并原子切换 current_。一个 WriteBatch 引起的数据变化，只有在对应 Version 被原子提交后才对所有读者完全可见——这就在全局层面巩固了原子语义。

三、工程实践要点

WriteBatch 的双重价值

性能价值容易被忽略：每次写入都要获取全局锁、可能触发磁盘同步。把 N 个操作放进一个 WriteBatch，一次锁、一次日志同步、一次内存表更新完成 N 个写入——吞吐显著提升。

边界：原子性不覆盖读-改-写

一个关键限制：WriteBatch 的原子性是"写入时"的原子，不提供"读取-修改-写入"这类多步交互的原子性。经典的反例是计数器：两个客户端同时读到 10，各自加 1 都写成 11，最终是 11 而不是 12。解决这类问题需要锁或乐观并发控制，WriteBatch 本身不提供。

⚠️ 常见坑：以为 WriteBatch 能当完整事务用，在"读-改-写"场景里依赖它的原子性，结果出现丢失更新。它的原子性边界只覆盖"一批写操作"，不覆盖跨读写的复合流程。

💡 关键直觉：把 WriteBatch 想成"一摞要一起盖章的文件"。盖章员（WAL）拿到这一摞后，一次操作（一次写日志）就在档案里留了记录，之后逐页处理（应用 MemTable）。中间任何一步出事，凭档案记录能原样重来——这就是"日志先行 + 批量"的原子性。

SOURCE 独有事实

WriteBatch 的内存管理有一个实用细节：它内部通常用一个连续内存区域（std::string）存储编码数据，高级用法中可复用 WriteBatch 对象减少构造开销，但每次使用前要调用 Clear()。另外，WAL 日志记录格式包含校验和、长度、批次数据，保证日志本身的完整性——这是崩溃恢复能准确判断"哪条记录是完整的"的关键。

四、深入展开：原子性的工程实践与边界

校验和：原子性的隐形守护者

WAL 记录里的校验和（Checksum）是容易被忽略、却极其关键的设计。它解决的是"写了一半的日志怎么识别"的问题：系统崩溃可能发生在写入的任意字节处，日志文件尾部可能是一条残缺的记录。没有校验和，恢复时无法区分"完整的记录"和"写了一半的残片"。

有了校验和与长度字段，恢复逻辑可以这样判断：从日志头开始，逐条读取——读到的长度和校验和匹配，就是完整记录，应用它；不匹配，说明从这条开始是残缺的，停止重放。这个"校验和即完整性边界"的设计，让崩溃恢复变得简单可靠。它也解释了为什么日志记录要带上"批次数据"整体计算校验——校验对象必须是"一个完整的原子单元"。

WriteBatch 复用与内存的细节

SOURCE 提到 WriteBatch 可复用（每次用前 Clear()），这个细节在性能敏感场景有意义：高频写入时，反复构造/析构 WriteBatch 对象会带来大量小分配。复用减少了对象构造开销，但要求开发者自律——忘记 Clear() 会导致旧数据残留，原子性被破坏。

这个细节也暗示了 LevelDB 的 API 设计取向：它把性能优化的空间留给用户，自己保持接口简单。你想在吞吐上压榨最后一分，就自己管理复用；你图省事，每次新建也没问题。这种"简单默认 + 进阶可调"的接口哲学，贯穿 LevelDB 的整个 API。

原子性在崩溃场景下的三种结局

把"先写日志再改内存"的流程放在崩溃显微镜下看，原子性保证系统只能停在三种合法状态之一：

1. WAL 未写完就崩溃：该批次整体视为未发生，重启后不恢复——正确
2. WAL 写完、MemTable 未应用完就崩溃：重启后重放 WAL 完整恢复整批——正确
3. 两者都完成：正常提交——正确

没有第四种"中间态"：不可能出现"批次的一半生效"。这就是"先日志后内存 + 整批写日志"的原子性承诺。任何声称支持原子写但实现不是这个结构的系统，要么靠事务日志，要么靠某种等价机制——你可以用这个框架去检验任何存储系统的原子性设计。

常见问题

问：WriteBatch 有大小限制吗？ 没有硬性限制，但过大批次会带来两个代价：一是单次 WAL 写入变长，fsync 时间变长；二是崩溃恢复时重放时间变长。实践中按业务批量规模来，通常几千条一批是合理的。

问：多个线程可以各自建 WriteBatch 并发提交吗？ 可以。WriteBatch 的构造是线程独立的，提交时由 LevelDB 的写队列串行化。并发调用 Put 是线程安全的，只是内部会排队。

问：WriteBatch 能跨数据库用吗？ 每个 WriteBatch 绑定一个数据库实例使用，不通用。因为批次里没有"数据库标识"，混用会导致数据写入错误的库。

原子性在真实业务里的两种用法

WriteBatch 的原子性在业务层有两种截然不同的用法，值得区分。第一种是"正确性用法"：业务逻辑要求多个键必须一起变化（如账户转账、倒排索引维护），依赖 WriteBatch 保证"全成或全不成"。第二种是"性能用法"：业务并不需要原子性，只是把多个独立写打包提交，享受"一次锁、一次日志同步、一次内存更新"的摊销收益。

理解这两种用法的区别很重要：如果你只是追求性能，WriteBatch 包不包无所谓（包了更好）；如果你依赖原子性，就必须理解它的边界——它只保证"一批写入的原子"，不保证"读-改-写"的原子。把性能用法误当正确性用法，或者反过来，都容易踩坑。这是面试和实际开发中都高频出现的考点。

原子性思维的可迁移性

"先写日志，再改状态"这个模式，不只属于 LevelDB——它是所有可靠系统的通用配方。文件系统的日志型文件系统、数据库的事务日志、消息队列的持久化、甚至分布式系统的一致性协议，底层都有"先记一笔，再动手"的影子。理解了这个模式，你就拥有了分析任何"保证不丢数据"系统的通用工具。

更进一步的启示是：可靠性的核心不是"更快的操作"，而是"可恢复的操作"。LevelDB 不求写操作永远成功，只求失败后能从日志恢复到一致状态。这个视角的转变——从"避免失败"到"让失败可恢复"——是现代分布式系统设计的基石，也是 LevelDB 作为教材的深层价值。

原子性的另一种视角：幂等与重放

理解 WriteBatch 的原子性，还可以从"重放"的角度看：WAL 中的记录本质是"可重放的操作描述"。系统崩溃后重放日志，本质上是在"重新执行"一批已经确认过的操作。要做到重放不出错，操作描述必须是"幂等友好"的——即重复执行不会产生错误结果。

LevelDB 通过"序列号 + 版本"保证了重放的一致性：每条记录带全局序列号，重放时按序列号顺序执行，且每个键只保留最新版本。这意味着即使某条记录被重复处理（比如日志里出现两次），最终状态也不会错——因为版本机制天然收敛到"最新序列号胜出"。理解"重放必须幂等"这个要求，你就明白了为什么 WAL 记录要携带完整的操作信息（键、值、类型、序列号），而不是只记一个"动作名字"。

本章回顾

• 要点一：WAL 先写日志再改内存，是持久性与原子性的基石。
• 要点二：WriteBatch 把多操作捆绑为不可分割单元，整体提交。
• 要点三：整批连续写日志 + 共享序列号，实现"全成或全不成"。
• 要点四：sync 决定是否 fsync，是持久性与性能的权衡点。
• 要点五：WriteBatch 兼具正确性（事务模拟）与性能（摊销开销）双重价值。
• 要点六：原子性不覆盖读-改-写复合流程，跨读写需要外部同步。

原子性保证了"写下去是对的"。下一节看读者的保障——快照如何让一个读取看到"凝固的过去"。