分布式文件系统Frangipani核心架构：锁、缓存与日志恢复

LEC 11的Frangipani论文，我前后读了三遍才算真正吃透。第一遍看完只觉得它是一个比较特别的分布式文件系统，第二遍才意识到它把“分布式锁+客户端缓存+私有日志”这三个基础组件组合出了一种极其优雅的架构，第三遍时我自己动手写了一个简化版，才明白论文里那些看似轻描淡写的细节——log_end指针的更新顺序、锁的释放时机、缓存写回的触发条件——才是整个系统最难的地方。

这篇文章想把Frangipani从头到尾拆开讲清楚。包括它当年在解决什么问题，锁和缓存怎么配合，崩溃恢复到底怎么做到不丢数据，以及我在复现核心流程时踩过的坑。如果你是做分布式系统、存储系统或者正准备系统设计面试的人，这篇东西应该能帮你把“分布式文件系统”这个概念从口号变成可落地的认知。

1. Frangipani在解决什么问题：本地缓存与共享存储的死结

1.1 那个年代的分布式文件系统之痛

90年代初，NFS这类网络文件系统已经普及了，但它的痛点非常明显：所有读写请求都要打到中心服务器上，客户端本地缓存形同虚设。为了性能，客户端当然希望把读写过的数据留在本地内存里，但一旦多个客户端同时改同一个文件，大家的缓存会互相覆盖，数据一致性根本没法保证。

Frangipani想要回答的问题很朴素：一群机器共享同一个文件系统，能不能既像本地文件系统一样快，又有严格的缓存一致性？那个时代的主流思路是“文件系统在服务端，客户端只当哑终端”，性能上不去；Frangipani反着来，把文件系统的“大脑”放到每个客户端节点上，让每个节点都带完整缓存，同时用一把全局锁来协调所有人，谁拿锁谁就能动对应的数据。

我当时看到这个设计的第一反应是：这不就是把“分布式一致性问题”外包给锁服务了吗？没错。但问题在于，外包之后如何保证锁本身不成为瓶颈、不成为单点，以及节点崩溃后锁状态怎么恢复。Frangipani对这三个问题的处理方式，才是它真正值得读的地方。

1.2 三类角色的清晰分工

Frangipani的架构里有三类角色，一眼就能看懂：

第一类是若干台前端服务器，论文里叫Frangipani服务器。它们运行用户态文件系统代码，每个服务器拥有自己的缓存，文件系统所有复杂的逻辑——路径查找、权限检查、数据块分配、inode管理——都在这里完成。客户端通过内核模块挂载后，本质上就是和某一台前端服务器打交道。

第二类是共享的物理存储。它不是直接暴露裸磁盘，而是以虚拟磁盘的形式出现。每台前端服务器都认为自己独占了一块或多块虚拟磁盘，但实际上这些磁盘上保存的是整个文件系统的元数据和数据块。

第三类是分布式锁服务，论文里叫Petals。它负责维护所有文件、目录和磁盘块的锁状态，前端服务器在读写任何东西之前必须先拿到对应的锁。

这个分工的妙处在于：前端服务器之间不需要互相通信，所有协调都通过“锁服务+共享存储”间接完成。你不需要设计复杂的多节点同步协议，只需要保证锁服务是可靠的，前端之间的所有冲突都会被锁挡住。

1.3 为什么说这个架构很激进

放到今天看，Frangipani的架构思路可能不觉得新奇，但在当时非常激进。第一，它把文件系统的逻辑从内核搬到了用户态，这就意味着崩溃隔离，一个前端宕机不会拖垮整个系统。第二，它让每个前端都可以独立地做缓存，不需要频繁回源。第三，它明确承认了“分布式文件系统不需要共享内存，只需要共享磁盘和一套共识后的锁”。

这种“局部自治+全局协调”的思想，后来几乎被所有分布式存储系统继承了。我自己在做存储系统设计时，也常用这套思路来拆需求——先划分哪些状态必须全局一致，哪些状态可以本地缓存，然后只在必须一致的地方引入锁或共识。Frangipani是一个非常好的蓝本。

2. 分布式锁：缓存一致性的基石

2.1 锁到底是什么角色

在Frangipani里，锁的作用不是传统操作系统里那种保护临界区的互斥量，它更像是“缓存有效期的通行证”。

任何一台前端服务器如果要读取某个文件，必须先向Petals申请该文件的读锁。持有读锁期间，服务器可以放心地使用本地缓存的副本，因为锁协议保证了不会有其他人同时修改这个文件。如果要写，就得申请写锁。写锁是排他的，确保同一时刻只有一个写者在修改文件，其他节点既不能读也不能写。

我把这个机制理解成一个非常朴素的类比：一群人共享一个公共笔记本，但每个人手里都有草稿纸。你想看某一页内容，就去管理员那里拿一把写着“这一页”的钥匙，确认自己拿到的是最新版。如果只是读，可以多人同拿；如果要改，必须一个人独占。

这个机制的效果是：只要锁没问题，缓存里永远不会有脏数据，也不需要像NFS那样额外做“缓存失效广播”。一致性不是靠“通知”，而是靠“请求许可”天然保证的。

2.2 读锁和写锁的生命周期

要理解Frangipani的锁，得把请求流程完整过一遍。

读一个文件的流程是：先向锁服务请求该文件的读锁，拿到锁之后，检查本地缓存里是否有该文件的数据。如果缓存没有，就去共享磁盘上读；如果有，直接用。使用完毕之后，缓存不会立刻失效，锁也不会立刻释放，而是会保留一段时间。

写流程麻烦一些：先申请写锁，拿到后才能修改本地缓存中的数据块。修改完成后，数据并不会马上写回共享磁盘，而是等缓存达到阈值、或者锁被释放/被抢占时，才把脏数据刷下去。

这里面有个关键点：锁的释放时机决定了缓存写回的时机。如果一个文件的写锁还在自己手上，那么缓存里的脏数据可以安全地留着；如果别的节点需要这个文件，锁服务会强制当前节点释放锁，节点必须先把自己缓存里的脏数据写回磁盘，然后才交出锁。

这个“先写回，再释放锁”的顺序是整个系统一致性的命门。我在复现时发现，只要把这个顺序颠倒一下，立刻会出现两个节点同时拥有同一份数据不同版本的问题。

2.3 锁粒度与锁缓存：性能和一致性的平衡

如果每次读写一个字节都要申请全局锁，性能肯定是灾难。Frangipani的应对方式是：

第一，锁有粒度区分。文件和目录都有自己的锁，目录锁保护目录项操作，文件锁保护文件内容。这样不同目录下的操作可以并行。

第二，锁可以被缓存。拿到锁之后不是用完立刻还，而是可以“持有”一段时间。在缓存锁期间，如果本地再次访问同一个文件，不需要重新请求锁。这种方式大幅减少了锁服务的通信压力。

但锁缓存引出一个问题：如果节点A缓存了文件X的读锁，节点B想写文件X，锁服务必须把A的锁“撤回”。A收到撤回请求后，必须放弃缓存锁，并且丢弃对应文件的缓存内容（因为内容可能已经不是最新了）。

这个回收机制听上去简单，做起来非常容易出错。Frangipani的做法是：锁服务只能保证“锁的归属状态”，能不能顺利撤回取决于前端服务器是否配合。如果前端服务器已崩溃，锁服务需要依赖租约机制——超过一定时间锁自动失效——来收回锁。租约的存在，让“节点崩溃”和“正常释放锁”在锁服务眼里没有本质区别。

2.4 用伪代码看访问流程

下面我用非常简化的伪代码描述写文件的核心流程，目的是让你看清“锁→缓存→写回”的顺序：

def write_file(fd, offset, data): lock = lock_service.acquire(fd.inode, mode="write") # 拿到写锁后，磁盘和缓存中最新的数据都属于当前节点 if inode not in local_cache: local_cache[inode] = read_from_shared_disk(fd.inode) mutate(local_cache[inode], offset, data) mark_dirty(inode) # 不会立刻写盘，而是等写回条件触发 return ok def flush_if_needed(inode): if cache_watermark_exceeded(): for inode in dirty_inodes: write_back_to_shared_disk(inode) # 只有在释放锁之前才会强制写回 def release_write_lock(inode): flush_to_shared_disk(inode) # 必须先落盘 lock_service.release(inode, mode="write") # 落盘之后，其他节点拿锁才能看到最新数据 drop_local_cache(inode)

注意release的注释：必须先落盘再释放锁。如果先释放锁再写盘，另一个节点会在还没看到最新数据的情况下就拿到锁并开始读写，那整个一致性就毁了。Frangipani的论文原理和我实际验证的结论完全一致。

3. 私有日志与崩溃恢复：如何让每台服务器“死得起”

3.1 为什么缓存型文件系统最怕崩溃

只要引入本地缓存，就必然面临一个问题：节点崩溃时，缓存里的脏数据可能还没来得及写回共享磁盘。如果是纯数据块丢失，也许还有办法；但如果元数据操作（比如创建文件、删除目录项、修改inode）写到一半就断了，共享磁盘上的文件系统就会处于一个中间状态，可能是目录项存在但inode不存在，或者数据块被标记为空闲但实际上还被引用。

传统文件系统的解决办法是写日志（journal）。Frangipani的特别之处在于，它不是全局共享一个日志，而是每台前端服务器维护自己的私有日志，写在共享磁盘上。这个设计非常重要，下文我会重点展开。

3.2 私有日志如何运作

每台Frangipani服务器在修改元数据之前，会先把“即将执行的元数据操作”以日志条目的形式追加写到自己的私有日志区域。日志条目包含操作类型、操作对象、必要的旧值和新值。写完日志之后，服务器才去修改缓存中的元数据。

关键点在于：日志输入的顺序必须和实际执行顺序一致，而且日志必须先落盘，再执行操作。这样即使操作执行到一半崩溃，恢复时也能通过重放日志把文件系统恢复到最后一个稳定状态。

那什么时候清理日志呢？一旦日志中某条操作对应的数据已经写回到共享磁盘的正式位置，这条日志就没用了。服务器会定期做checkpoint，推进日志的回收水位。

3.3 崩溃恢复的完整步骤

假设服务器A崩溃了，另一台服务器B接管恢复。恢复流程是这样的：

首先，B确认A的所有锁已经自动释放（通过租约超时机制）。然后B去A的私有日志区域，从上次checkpoint的位置开始，逐条读取日志记录。B把这些日志记录里的元数据操作重新执行一遍，确保共享磁盘上的元数据回到A崩溃前的状态。

这里有个细节值得细品：A可能已经执行了一部分操作，但日志写完之后操作没执行完。恢复时重放日志会把操作完整地再做一遍。由于日志操作设计成幂等的，重复执行不会产生错误结果。“先写日志再执行”这个顺序，保证了恢复过程不会丢失任何已确认的修改。

我在复现恢复流程时有一个很深的体会：Frangipani之所以敢让每个前端都带大缓存，是因为它把“缓存的易失性”和“日志的持久性”彻底分离了。缓存丢了无所谓，日志还在就行；日志是每个节点独立的，恢复时不需要和其他节点协商，只需要按自己的日志重放。这个设计极大降低了恢复的复杂度。

3.4 为什么私有日志比全局日志更好

如果多个服务器共享一份全局日志，写日志就变成了一个全局串行化瓶颈，而且崩溃恢复时所有服务器都要暂停，等全局日志扫完。Frangipani用私有日志，每台服务器只需要关心自己崩溃后的恢复，别人崩溃了和自己没关系。

这个“故障隔离”听起来容易，实现时有一个麻烦：不同服务器的日志写在同一块磁盘上，它们的操作可能会影响同一个文件系统的元数据。假设服务器A修改了文件X的inode，随后服务器B修改了同一个文件X的另一个字段，两个日志条目之间是否有依赖关系？Frangipani的答案依赖于锁。任何对同一个元数据的修改都受同一把写锁保护，所以在时间上，A和B对文件X的修改是串行化的；恢复时任意顺序重放这些日志，都不会产生逻辑矛盾。

用一句话总结就是：锁保证了不同日志之间的可交换性，私有日志因此可以独立恢复。这是我读这篇论文时觉得最漂亮的一点。

4. 从零实现一个简化版Frangipani核心

4.1 实验环境与模块划分

纸上谈兵没有意义。我在某分布式存储方向的模拟项目里，用三台主机和一台共享存储模拟器复现了Frangipani的核心。这里给你一个可以照抄的简化设计。

模块划分如下：

• LockService：独立运行在一台机器上，维护所有锁的归属状态和租约时间。
• CacheNode：模拟一台Frangipani服务器，持有缓存、维护脏页列表、执行日志写入。
• SharedDisk：用一块模拟磁盘文件，存储所有元数据和数据块。
• LogRegion：每个CacheNode在SharedDisk上独占一段区域，用于存放私有日志。

每个CacheNode启动时先做两件事：向LockService注册；检查自己的LogRegion，如果有上次崩溃留下的日志，先执行恢复流程。

4.2 关键接口与伪代码

下面给出核心接口设计，用Go风格的伪代码：

type LockService interface { Acquire(path string, mode LockMode, leaseTime time.Duration) (Lock, error) Release(lock Lock) Revoke(lock Lock) error // 强制回收 } type CacheNode struct { disk *SharedDisk locks LockService cache map[string]*CachedFile dirty map[string]bool logRegion string } func (n *CacheNode) Write(path string, data []byte) error { lock := n.locks.Acquire(path, WriteMode, defaultLease) defer n.locks.Release(lock) file := n.getCachedFile(path) // 缓存未命中则从磁盘读 // 1. 先写日志 n.appendLog(LogEntry{Op: "write", Path: path, Data: data, Ver: file.version + 1}) // 2. 修改缓存 file.Apply(data) file.version++ n.cache[path] = file n.dirty[path] = true // 3. 如果脏页达到阈值，主动写回 if n.DirtyRatio() > 0.95 { n.flush() } return nil } func (n *CacheNode) flush() { for path := range n.dirty { n.writeBack(path) // 写回共享磁盘正式区域 n.logRegion.SetCheckpoint(path) // 日志可以截断到该位置 delete(n.dirty, path) } }

要注意appendLog必须同步刷盘成功才能返回。我一开始图省事，把日志写入当成异步操作，结果一跑并发就出现各种诡异问题：日志还没落盘，操作已经在缓存里执行了，紧接着节点崩溃，恢复时日志里根本没有这条操作，修改就丢了。这个教训让我彻底记住了“先日志后操作”的铁律。

4.3 重要参数与取舍

复现过程中有几个参数会严重影响系统行为，我列一个表方便你对照调参：

一个小技巧：把锁租约时间设置成心跳间隔的三倍以上，这样正常的网络抖动不会引发锁误释放。我自己在实验里把租约设成10秒、心跳设成3秒，跑了一整天没有出现过一次误判。

4.4 实测效果与调优心得

简化版跑通之后，我做了个测试：三台CacheNode同时对一个目录做大量创建和删除文件操作。如果不用锁、只看本地缓存，文件数会越跑越偏，两个节点看到完全不同的目录内容。加上锁服务之后，三个节点长时间运行后最终看到的目录内容完全一致，没有任何一个文件出现“我看到了但你不存在”的情况。

再测崩溃恢复：我随机kill掉一个CacheNode进程，另一个节点接管恢复日志，重新扫描目录，最终目录内容和kill之前一致，没有丢文件，也没有出现残留的半截目录项。这里我得到一个实操经验：恢复代码一定不能假设日志区域是完整有序的。崩溃可能发生在日志写到一半的时候，尾部可能有半条无效记录，恢复逻辑必须能识别并跳过它，否则整个恢复流程会被一条残缺记录卡死。

5. 常见问题与排查避坑实录

5.1 锁服务是否会有单点问题

Frangipani的锁服务独立运行，天然存在单点风险。一旦锁服务挂了，所有前端节点上的锁缓存都会因为没有续租而陆续过期，整个文件系统会进入“只读但不许改”的状态。论文并没有给锁服务做高可用，这是那个年代架构的局限。

我在实际环境中用了一个临时的HA方案：锁服务一主一备，主节点通过心跳把锁表同步到备节点，主节点宕机后备节点在几秒内接管。但要注意，备节点接管时必须包含完整的租约信息，否则所有前端锁全部强制失效，代价很高。

5.2 日志区域无限增长怎么办

如果CacheNode长时间运行，但从来不触发写回，私有日志会一直增长。Frangipani的做法是定期做checkpoint，把日志里已经完成的、且数据已落盘的操作标记为可回收。

我自己遇到的坑是：checkpoint逻辑容易和写回逻辑抢锁。checkpoint在扫描日志时，不允许同时有写操作推进旧日志水位，否则会出现“日志已回收但操作还没落盘”的严重bug。解决办法是让checkpoint和flush共用同一把元数据锁，宁可让checkpoint慢一点，也不能让数据和日志错位。

5.3 缓存与锁的回收顺序

这是最容易犯错误的地方。正确的顺序是：收到锁回收请求→把脏数据写回磁盘→丢弃本地缓存副本→向锁服务回复“释放成功”。一旦顺序变成“先释放后写回”，另一个节点拿到锁后可能读到旧数据，整个文件系统的缓存一致性就塌了。

我在代码里用了一个状态机来防止这种错误：每个缓存条目只有“clean”和“dirty”两种状态，dirty状态下禁止响应锁释放，必须等待写回完成。这样从代码结构上杜绝了顺序错乱。

5.4 目录项和inode的一致性问题

Frangipani里目录项和inode各有一把锁，创建文件时可能要同时操作目录和inode。如果两个锁不是一起申请、一起释放，就会出现“目录里能看到某个文件，但inode还没初始化完成”或者“inode已经分配但目录项不见”的中间态。

我处理这个问题的办法是引入一个“元操作锁”：把创建文件、删除文件、重命名这类需要多对象原子操作的行为，统一申请一把系统级操作锁，然后再分别申请目录锁和inode锁。这样多锁的顺序始终一致，死锁和中间态都更容易控制。

6. Frangipani给后来者的启示

6.1 锁+缓存+日志的通用范式

Frangipani这套“锁服务决定谁能碰缓存，日志决定崩溃后怎么恢复”的组合，在之后的分布式存储系统里反复出现。很多后来系统的单机存储引擎里，你能看到相似的日志恢复机制；而在分布式协调层面，租约、锁缓存、锁回收这些概念也几乎成了标配。

读Frangipani之前，我总觉得分布式文件系统一定需要某种“魔幻”的方案才能同时做到一致性和高性能。读完才发现答案全是用最基础的东西搭起来的：锁保证互斥，缓存保证性能，日志保证持久性。关键在于如何把它们按正确的顺序组织好。

6.2 故障隔离思想的延伸

Frangipani让每台服务器都只处理自己的日志，这让“一台机器崩溃”从全局灾难变成了局部事件。后续许多系统在设计时都吸收了类似思想：把共享状态尽量做成局部可恢复的，而不是让所有节点一起背锅。

我自己在做系统设计时，会把这条当成一个原则来用：每次引入新的共享状态，就问自己一句“如果持有它的节点今天下午突然死了，其他人怎么恢复？”如果答不上来，说明这个设计还不够干净。

6.3 我个人的体会

重读Frangipani最大的收获，是它让我重新理解了“操作顺序”在分布式系统中的分量。新增一个并发算法、调大一个缓存参数，这些当然重要，但真正决定系统对错的，永远是那些看似不起眼的顺序约束——先拿锁后读缓存，先写日志后改内存，先写回后放锁。把这些顺序背下来不难，难的是在每个模块里都严格执行，不让任何一条代码路径绕过这些约束。

如果你也想复现这套系统，我会给你一个很具体的建议：先不要追求复杂功能，只实现read、write、mkdir三个操作，把锁、缓存、日志、恢复四条链路全部跑通，然后再考虑并发优化。我当初跳过这个阶段直接上功能，结果debug的时间是写代码时间的三倍。这个坑，希望你能绕过去。