分布式存储WAL：预写日志怎么保证一致性

可视化演示

展示WAL预写日志写入四阶段流程、Raft多节点日志复制同步及崩溃恢复回放机制，揭示预写日志保证分布式存储数据一致性的核心原理。

WAL基本概念：账房先生的铁规矩

永昌钱庄的老账房有个传了三代的规矩：无论多忙，先记流水簿，再誊总账本。伙计觉得多此一举，老账房说：“总账本可能被烧、被抢、被虫蛀，但流水簿是每天最早落笔的记录，只要它在，任何一笔账都能重新誊出来。”这个朴素的直觉，就是预写日志（Write-Ahead Logging，WAL）的起源——先写日志，再动数据。

数据库里的 WAL 遵循同一顺序：收到写操作，先把操作以追加形式写入日志文件，日志确认落盘后，才修改真正的数据页。为什么这么绕？因为数据页是随机读写的，而日志是顺序追加的。磁盘顺序写让机械臂像推土机一样平推过去，随机写却要反复寻道摆动，两者性能可以差几十上百倍。更重要的是安全：日志落盘了，数据哪怕只改了一半就崩溃，重启时重放日志就能补齐；日志没落盘，说明操作从未被承诺，直接当作没发生——这就是事务原子性的边界。

老账房那句“先记后誊”扛过了三任东家，WAL 这条铁律也扛过了无数真实的数据库崩溃事故。理解了这个顺序，你就拿到了理解一切存储系统（MySQL 的 redo log、RocksDB 的 WAL、Kafka 的 partition 日志）的万能钥匙。

单机WAL原理：流水簿怎么记才不丢

老账房记流水有四道工序：蘸墨、落笔、晾干、誊账。他反复叮嘱徒弟：“晾干这道工序最不能省。墨迹没干就誊账，一阵穿堂风糊了字，月底对账就成了一笔糊涂账。”

单机 WAL 的写入流程同样分四步：第一步，把日志追加到内存缓冲区；第二步，调用 fsync 把缓冲强制刷入磁盘——这正是“晾干墨迹”；第三步，把改动应用到数据页；第四步，向客户端返回成功。若在第二步之前崩溃，日志还在操作系统页缓存里，断电即失；只有 fsync 完成，日志才真正“干透”。

fsync 是昂贵的操作，一次可能耗费数毫秒，而内存写入只要微秒级。为了摊薄成本，数据库普遍采用组提交（group commit）：攒一批日志，一次性刷盘，让昂贵的磁盘操作被 N 条日志平分。

墨没晾干就誊账，等于日志没落盘就返回成功——停电瞬间，客户的钱就“蒸发”了。单机 WAL 的全部秘密，就是把“晾干”这道工序做成不可省略的硬性门槛。

一致性挑战：分号多了对不上账

钱庄开成连锁后，麻烦接踵而至。保定分号柜上收了银子，记在自己的流水簿上，可京城总号不知道；等年底对账，两本账怎么也对不齐。更棘手的是：保定分号的账房先生突然辞工跑了，他那本流水簿再也没人看得懂。

分布式系统把数据复制到多台机器（称为副本），本质就是开连锁分号。单机 WAL 只保证“本号”的账不丢，但多个副本之间必须就日志的内容和顺序达成一致，否则每个分号各记各的，系统整体就是一本烂账。分布式场景下有三大敌人：节点故障——账房先生跑了；网络分区——传话的伙计被堵在半路，两边互相联系不上；脑裂——两个分号都以为自己是总号，各自拍板，账目分叉。

CAP 定理给出了残酷的答案：网络分区（P）是分布式系统的必然前提，一旦发生，一致性（C，所有节点读到相同数据）和可用性（A，每个请求都有响应）只能二选一。于是人们发明了共识协议（Raft、Paxos），用“投票 + 日志复制”的机制，让所有节点对账本形成唯一共识。

老东家拍板：“宁可关店，也不能记错账。”所以强一致系统（如 TiKV、etcd）在分区时宁可拒绝写入也不返回脏数据——这正是 Raft 这类共识协议存在的意义。

Raft日志复制：总账房拍板，分号抄录

为了根治分号对不上账，东家立了新家规：设一位总账房（Leader），全城所有账目由他一人拍板；各分号（Follower）收到指令后抄录一份，并回执“收到”。任何分号不得私自记账。

这就是 Raft 协议的工作方式。集群先通过选举选出一个 Leader（相当于总账房选举，任期内只有一个当家人）；客户端的所有写请求只发给 Leader；Leader 把新日志通过 AppendEntries RPC 广播给所有 Follower；Follower 按收到的顺序追加到自己的日志并回执。为了防止“两个总号”的脑裂，Raft 引入任期（term）机制——Leader 失联后，Follower 将任期号加一再竞选，老的 Leader 回来发现任期落后，自动退位。

Raft 最精妙的是日志匹配性质：如果两条日志条目的序号（index）和任期（term）都相同，那么它们的日志内容必定相同，而且在此之前的所有日志也完全一致。这保证所有副本的日志前缀相同，为后续提交和恢复打下根基。

新总账房上任第一件事，就是翻前任留下的流水簿和各分号对账，把不一致的旧账逐条校准。Raft 选举结束后的日志对齐也是这样：Leader 找到双方共同的最新日志位置，强制落后的 Follower 补齐或回退。

提交与持久化：什么时候算板上钉钉

分号回执“收到”还不算数。老东家定下新规矩：总号加至少过半分号都回执“已誊录完毕、墨已晾干”，这笔账才盖上“已结”的朱砂印。只回来一个分号的回执？这笔账就悬着，谁也不敢认。

Raft 的提交规则如出一辙：Leader 确认某条日志被多数派（quorum）节点持久化后，才更新提交位（commitIndex），并向客户端返回成功。为什么要“过半”而不是“全部”？全部确认在故障时会锁死系统——任何一个分号失联，整笔账就永远无法盖章；而过半只需要大多数活着。更深层的数学原因是：任意两个多数派之间必有交集（至少共享一个节点），这个节点一定持有最新日志，新 Leader 当选后必然不缺账。

{% math %}

N_{\text{quorum}} = \left\lfloor \frac{N_{\text{节点}}}{2} \right\rfloor + 1

{% endmath %}

1. 总数 N：集群中参与投票的节点总数

$$N_{\text{节点}}$$

2. 半数取整：先计算总数一半的整数部分

$$\left\lfloor \frac{N_{\text{节点}}}{2} \right\rfloor$$

3. 加一得多数：半数加一构成多数派，任意两个多数派必有交集

$$N_{\text{quorum}} = \left\lfloor \frac{N_{\text{节点}}}{2} \right\rfloor + 1$$

fsync 的时机同样关键：Follower 收到日志必须先刷盘再回执，绝不能只写入页缓存就回复“已收到”，否则账房嘴上说誊好了，实际墨迹还在砚台里。过半回执 = 盖章生效。三个分号只回来一个，账就悬着——宁可让客户等，也不能假盖章。

日志截断与快照：流水账太厚怎么办

流水簿日复一日地记，十年后库房里堆满了发黄的账册。老账房想了个办法：每月月底结账一次，把当月已结清的旧账装订成一册“月结册”，册子里只有每笔账的最终结果，之后的新流水另起新簿继续记。

分布式系统的日志同样会无限膨胀：每一条写操作都追加到日志，磁盘迟早被撑爆，崩溃重放也会越来越慢。Raft 的解决方案就是快照（snapshot）：把某个时刻的完整数据状态固化成一份文件，该时刻之前的日志就可以安全删除。日志压缩的本质不是“删账”，而是“把已结清的旧账换算成一张总表”。

对于落后的节点（比如新加入的分号），Leader 可以直接把快照发过去安装，再补齐快照之后的少量日志，免去从盘古开天开始重放。注意一个原则：日志始终是追加写模式（Append-only），永远不会修改或回填旧条目，只做“截断 + 快照”的压缩动作。

流水簿烧旧册，新簿接着记——快照不是删账，而是把历史折算成一张总表。只要月结册和后续流水都在，账就永远完整，这也让跨节点的日志同步在工程上变得可行。

故障恢复一致性：重新开张怎么找回账

最坏的事情还是发生了：保定分号半夜失火，账房、账本、流水簿烧了个精光。重新开张那天，新任账房带着从京城总号拿来的月结册以及总号的流水副本，从失火前那个时点开始一笔笔重演，硬是把整本账盘了回来，分毫不差。

分布式节点的恢复正是这个流程：崩溃重启后，先加载最新快照，再重放快照点之后的 WAL 日志，逐步追平提交位。单机场景下靠本机 WAL 重放；分布式场景下，Leader 会通过 AppendEntries 检查 Follower 的日志进度，发现落后就逐条补发，落后太多则直接安装快照。每一步都带着校验（checksum、任期号、序号），防止“脏账”混入。

为什么最终能收敛到一致？因为无论哪个节点，只要遵循“同一个快照 + 同一串日志”，按同样的顺序应用，必然得到同样的状态。这也是分布式系统一致性的终极保证：不是靠运气，而是靠确定性的重放。

老账房临终前留下一句话：“账烧了没关系，流水簿和月结册在，账就永远在。”WAL 和快照，就是分布式系统那两本永远烧不掉的册子。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""WAL 预写日志 + Raft 式日志复制的最小演示"""import os  class WAL:    """单机预写日志：先追加日志，再让上层应用改数据"""     def __init__(self, path="wal.log"):        self.path = path        self.entries = []        if os.path.exists(self.path):            os.remove(self.path)     def append(self, entry):        """追加一条日志并立刻 fsync，保证落盘"""        with open(self.path, "a") as f:            f.write(entry + "\n")            f.flush()            os.fsync(f.fileno())        self.entries.append(entry)     def replay(self):        """崩溃后重放日志，恢复出状态字典"""        state = {}        if not os.path.exists(self.path):            return state        with open(self.path) as f:            for line in f:                line = line.strip()                if not line:                    continue                parts = line.split()                if len(parts) == 3 and parts[0] == "SET":                    state[parts[1]] = int(parts[2])        return state  class KVStore:    """带 WAL 的 KV 存储：先写日志，再改内存数据"""     def __init__(self):        self.data = {}        self.wal = WAL()     def set(self, key, value):        self.wal.append("SET %s %d" % (key, value))        self.data[key] = value     def recover(self):        self.data = self.wal.replay()        return self.data  class Replica:    """Raft 复制中的一个节点，保存日志副本"""     def __init__(self, name):        self.name = name        self.entries = []        self.commit_index = -1     def append_entries(self, entry):        self.entries.append(entry)  def raft_replicate(cluster, entry):    """Leader 把日志广播给所有节点，过半确认才算提交"""    leader = cluster[0]    leader.entries.append(entry)    acks = 1    for node in cluster[1:]:        node.append_entries(entry)        acks += 1    if acks > len(cluster) // 2:        for node in cluster:            node.commit_index = len(node.entries) - 1        return True    return False  def demo():    store = KVStore()    store.set("balance", 100)    store.set("balance", 200)    print("模拟崩溃后重放:", store.recover())     cluster = [Replica("n0"), Replica("n1"), Replica("n2")]    ok = raft_replicate(cluster, "SET balance=300")    print("过半提交成功:", ok)    for node in cluster:        print(node.name, node.entries, "commit=", node.commit_index)  if __name__ == "__main__":    demo()

1. os.fsync(f.fileno())把日志从页缓存强制刷入磁盘，模拟“墨迹晾干”这一不可省略的工序
2. self.wal.append("SET %s %d" % (key, value))先写日志，这是 WAL 的第一原则
3. self.data[key] = value日志落盘成功后才修改内存数据，顺序绝不可颠倒
4. store.recover()模拟崩溃后重放日志，从磁盘流水恢复出全部状态
5. acks > len(cluster) // 2统计超过半数节点确认，才判定日志提交成功
6. node.commit_index = len(node.entries) - 1提交后同步推进所有节点的提交位置

常见误区

面试题