3.1 为什么顺序写入快#

顺序追加写入之所以快，是因为磁盘在顺序写入时不需要频繁寻址。即使是 SSD，顺序写入也远快于随机写入——SSD 的写入以页为单位，但擦除以块为单位，顺序写入可以让垃圾回收和写放大降到最低。WAL 把所有修改组织成顺序追加的日志流，正好利用了这个特性。

3.2 重放的顺序与幂等#

WAL 重放有一个隐含的前提：日志条目必须按写入顺序重放。这不是可选的，而是必须的。考虑这样一个场景：日志里有两条操作，[1] SET x=1 和 [2] SET x=2。如果倒序重放，先执行 [2] 再执行 [1]，最终 x=1——但正确结果应该是 x=2。顺序重放保证后写入的操作覆盖先写入的操作，与正常执行的效果一致。

幂等性是另一个关键前提。所谓幂等，就是同一个操作执行一次和执行多次的效果相同。SET x=5 是幂等的——执行多少次 x 都是 5。但 INCREMENT x BY 1 不是幂等的——执行一次 x 加 1，执行两次 x 加 2。如果日志里包含非幂等操作，重放时就需要额外的机制来追踪哪些操作已经应用过，比如用事务 ID 或操作序列号来去重。

3.3 日志压缩与检查点#

WAL 有一个现实问题：日志会无限增长。如果系统运行了三个月，每秒写入 1000 条日志，日志文件会膨胀到几十亿条。崩溃后从头重放整个日志？恢复时间可能比崩溃前的运行时间还长。

解决方案是两个配合使用的机制：日志压缩（Log Compaction）和检查点（Checkpoint）。检查点是把当前完整状态写入一个快照文件，日志中检查点之前的条目就可以安全丢弃。恢复时先加载最近的检查点快照，再重放检查点之后的日志条目——可能只有几分钟的量，而不是几个月的。

日志压缩则更精细：不是一刀切地截断日志，而是扫描日志，对于同一个 key，只保留最新的操作，丢弃被覆盖的历史操作。比如日志里有 SET x=1、SET x=2、SET x=3，压缩后只保留 SET x=3。Kafka 的日志压缩（Log Compaction）就是这种思路——每个 topic partition 的日志只保留每个 key 的最新值。

3.4 WAL + MemTable 写入流程#

上面讨论的是 WAL 作为通用日志的写入模式。在 LevelDB、Bigtable 这类 LSM 存储引擎中，WAL 和内存中的有序结构（MemTable）紧密配合，形成一条完整的写入流水线：

1. 写入请求到达，先将操作追加到 WAL 文件并 fsync
2. 操作插入内存中的 MemTable（通常是跳表，保持有序）
3. 当 MemTable 大小达到阈值，将其标记为不可变（Immutable MemTable），同时创建新的 MemTable 继续接收写入
4. 后台线程将 Immutable MemTable 刷盘为 SSTable（有序的磁盘文件）
5. 刷盘完成后，对应的 WAL 文件即可安全删除

这条流水线的关键在于：WAL 保证持久性（崩溃后可重放恢复 MemTable 中的数据），MemTable 保证有序性（刷盘时直接输出有序的 SSTable），两者配合让写入路径全程顺序 I/O。值得注意的是，第 2 步完成后就返回成功，第 4-6 步都是后台异步执行的——写入延迟只取决于 WAL 追加和 MemTable 插入，不受刷盘影响。这也是 LSM 树写入性能远超 B+ 树的根本原因。

4.1 WAL + 检查点的黄金搭档#

WAL 和检查点是经典的组合：WAL 保证每条操作不丢失，检查点限制 WAL 的大小。恢复时先加载最近的检查点，再重放检查点之后的 WAL 条目——比从头重放整个日志快得多。

这个组合的关键问题在于检查点的时机。太频繁，检查点本身的 I/O 开销大；太稀疏，日志过长，恢复慢。常见的策略有两种：基于时间（每隔 N 秒做一次检查点）和基于日志量（每积累 N 条日志做一次检查点）。PostgreSQL 用 checkpoint_timeout 控制时间间隔，MySQL InnoDB 则两者兼有。

还有一个细节：做检查点本身也需要时间，系统在写入检查点的过程中还在持续接收新操作。所以检查点必须记录一个”截止位”——表示这个快照包含了截止到哪个 LSN（Log Sequence Number）的所有修改。恢复时只需重放 LSN 大于截止位的日志条目。

4.2 事件溯源：WAL 的极端形态#

事件溯源（Event Sourcing）可以看作 WAL 的极端版本：不保存当前状态，只保存事件日志。状态永远从日志推导。想要知道账户余额？不是查一个 balance 字段，而是把该账户的所有 Deposit 和 Withdraw 事件加起来。

好处是完整的审计追踪——每一条状态变更都有据可查，甚至可以回溯到任意历史时刻。代价也显而易见：查询需要重放历史。实践中通常用快照（本质上就是检查点）来缓解：定期把当前状态序列化存储，查询时从最近的快照开始重放。

事件溯源和 WAL 的本质区别在于用途：WAL 是实现细节，对应用层透明，目的只是崩溃恢复；事件溯源是领域建模方式，事件本身就是业务模型的一部分。

4.3 LSM 树与 WAL 的关系#

LSM 树（Log-Structured Merge Tree）和 WAL 有深层的联系。LSM 树的所有写入都是顺序追加到 MemTable，MemTable 满了之后刷盘为有序的 SSTable——这本身就是一种 WAL 思想的延伸：把随机写转化为顺序写。不同之处在于，LSM 树的日志是数据本身，而 WAL 的日志是操作的记录。

实际上，很多 LSM 树的实现（如 RocksDB、LevelDB）在写入 MemTable 之前，仍然会先写一个 WAL。因为 MemTable 在内存中，断电就没了。WAL 在这里的作用是保证 MemTable 中的数据在崩溃后可以恢复。所以 LSM 树和 WAL 不是互斥的，而是互补的：LSM 树优化了数据的存储和查询结构，WAL 保证了写入的持久性。

5.1 Go 实现#

1
package wal
2

3
import (
4
  "bufio"
5
  "encoding/json"
6
  "os"
7
  "sync"
8
)
9

10
// LogEntry 日志条目
11
type LogEntry struct {
12
  ID        int                    `json:"id"`
13
  Operation string                 `json:"operation"`
14
  Data      map[string]any         `json:"data"`
15
  Applied   bool                   `json:"applied"`
16
}
17

18
// WAL 预写日志
19
type WAL struct {
20
  mu       sync.Mutex
21
  entries  []LogEntry
22
  nextID   int
23
  file     *os.File
24
  maxBytes int64 // 段文件最大字节数，超过则轮转
25
}
26

27
func New(path string) (*WAL, error) {
28
  f, err := os.OpenFile(path, os.O_APPEND|os.O_CREATE|os.O_RDWR, 0644)
29
  if err != nil {
30
    return nil, err
31
  }
32
  return &WAL{file: f, nextID: 1, maxBytes: 64 * 1024 * 1024}, nil
33
}
34

35
// Append 追加操作到日志，先写日志再返回
36
func (w *WAL) Append(op string, data map[string]any) (int, error) {
37
  w.mu.Lock()
38
  defer w.mu.Unlock()
39

40
  entry := LogEntry{
41
    ID:        w.nextID,
42
    Operation: op,
43
    Data:      data,
44
    Applied:   false,
45
  }
46
  w.nextID++
47

48
  // 先写日志——这是 WAL 的核心
49
  buf, err := json.Marshal(entry)
50
  if err != nil {
51
    return 0, err
52
  }
53
  buf = append(buf, '\n')
54
  if _, err := w.file.Write(buf); err != nil {
55
    return 0, err
56
  }
57
  // 确保持久化，不留在 OS 页面缓存
58
  if err := w.file.Sync(); err != nil {
59
    return 0, err
60
  }
61

62
  w.entries = append(w.entries, entry)
63
  return entry.ID, nil
64
}
65

66
// Recover 从磁盘日志文件重放恢复状态
67
func (w *WAL) Recover(applyFn func(LogEntry)) (int, error) {
68
  // 从头读取日志文件
69
  if _, err := w.file.Seek(0, 0); err != nil {
70
    return 0, err
71
  }
72
  scanner := bufio.NewScanner(w.file)
73
  count := 0
74
  for scanner.Scan() {
75
    var entry LogEntry
76
    if err := json.Unmarshal(scanner.Bytes(), &entry); err != nil {
77
      continue // 跳过损坏的行（可能是崩溃时写到一半的记录）
78
    }
79
    applyFn(entry)
80
    entry.Applied = true
81
    w.entries = append(w.entries, entry)
82
    count++
83
  }
84
  return count, scanner.Err()
85
}

Go 版本的核心在 Append 方法：先序列化、写文件、Sync()（相当于 fsync），确保日志落盘后才返回。这里有一个需要仔细权衡的决策：每条日志都 fsync() 还是批量 fsync()？ 每条都 fsync() 保证零数据丢失，但性能开销大——fsync() 会阻塞直到磁盘 I/O 完成，机械硬盘上可能需要 10ms 以上。批量 fsync()（比如每 100ms 调用一次）性能好得多，但可能丢失最后一次 fsync() 之后的几条日志。生产系统通常提供可配置的刷盘策略：PostgreSQL 的 synchronous_commit 参数、MySQL 的 innodb_flush_log_at_trx_commit 参数，本质上都是在回答同一个问题——你愿意用多少性能换多少安全性。

Recover 方法从磁盘文件逐行读取日志条目，跳过损坏的行——崩溃时可能写到一半就断了，最后一行大概率是残缺的 JSON，反序列化会失败，直接跳过就好。这也是 WAL 实现中常见的防御性处理：每条日志以换行符结尾，读取时按行分割，不完整的最后一行直接丢弃。

5.2 TypeScript 实现#

1
interface LogEntry {
2
  id: number;
3
  operation: string;
4
  data: Record<string, unknown>;
5
  applied: boolean;
6
}
7

8
class WriteAheadLog {
9
  private entries: LogEntry[] = [];
10
  private nextId = 1;
11

12
  /** 追加操作到日志（模拟持久化） */
13
  append(
14
    operation: string,
15
    data: Record<string, unknown>,
16
  ): number {
17
    const id = this.nextId++;
18
    this.entries.push({ id, operation, data, applied: false });
19
    // 生产环境：这里应该 fsync 到磁盘
20
    return id;
21
  }
22

23
  /** 应用所有未应用的日志条目 */
24
  apply(applyFn: (entry: LogEntry) => void): number {
25
    let count = 0;
26
    for (const entry of this.entries) {
27
      if (!entry.applied) {
28
        applyFn(entry);
29
        entry.applied = true;
30
        count++;
31
      }
32
    }
33
    return count;
34
  }
35

36
  /** 崩溃恢复：重放所有日志条目 */
37
  recover(applyFn: (entry: LogEntry) => void): number {
38
    let count = 0;
39
    for (const entry of this.entries) {
40
      applyFn(entry);
41
      entry.applied = true;
42
      count++;
43
    }
44
    return count;
45
  }
46
}

TypeScript 版本模拟了 WAL 的核心逻辑。生产环境中日志应写入持久存储（文件、IndexedDB 等），并在追加后确保刷盘。apply 和 recover 的区别在于：apply 跳过已应用的条目，recover 无条件重放所有条目——因为崩溃后不知道哪些已应用。

这里还有一个值得讨论的问题：浏览器环境中如何做持久化保证？Node.js 可以直接调用 fs.fsyncSync()，但浏览器里没有等价 API。IndexedDB 的写入是异步的，也没有 fsync 语义。浏览器环境的 WAL 更多是逻辑层面的保障——防止页面刷新导致的状态丢失，而不是断电级别的持久性。