Frangipani 的优雅：一部关于锁、日志与版本的分布式系统设计传奇
在分布式系统的世界里，“简单”往往是最高赞誉，而 Frangipani 文件系统（1997年）的设计，时至今日仍是“优雅简约”的典范。它没有采用复杂的集群成员管理，也没有P2P的节点间通信，而是构建在一个“反常”却极其强大的理念之上。
最近，我深入研究了其内部机制，仿佛在上一堂大师课。Frangipani 向我们展示了如何通过清晰的职责分离，将缓存一致性、事务原子性、崩溃恢复这三个最棘手的难题逐一解构。
这不仅仅是一个过时的文件系统，这是一个关于如何构建可扩展、高可用系统的永恒教程。
01. 核心架构：“反常”的无通信设计
Frangipani 的核心架构由三部分组成：
- Petal (共享存储)： 一个高可用的分布式虚拟磁盘。它扮演“肌肉”，只管存取数据块。
- 锁服务器 (LS)： 一个全局协调者。它扮演“交通警察”，只管发放和撤销锁。
- Frangipani 服务器： 运行文件系统逻辑，每个服务器都服务于自己的客户端，并持有本地缓存。
其设计的“黄金法则”也是最“反常”的一点：Frangipani 服务器之间从不直接通信。
它们所有的协调都通过“下游”的 Petal 和锁服务器完成。这一设计极大简化了集群管理（节点增删如插拔砖块），但也将所有压力抛给了锁系统。
02. 一切的起点：基于“撤销”的缓存一致性
Frangipani 必须解决第一个问题：当多个服务器都缓存了数据，如何保证一致性？
它采用了一种**基于锁的“写回”（Write-Back）**策略。我们来看一个经典流程：
- 获取 (Acquire): WS1（工作站1）想修改文件
Z。它首先向 LS 请求Z的“排他写锁”。 - 本地修改 (Dirty Cache): LS 授予锁。WS1 从 Petal 读取
Z，并在本地内存中修改它。此时，Petal 上的数据是“旧”的，WS1 的缓存是“脏”的。 - 争用 (Contention): 此时，WS2 想要读取文件
Z，它也向 LS 请求（读）锁。 - 撤销 (Revoke): LS 知道锁在 WS1 手里，于是它向 WS1 发送一条
Revoke（撤销）消息。 - 强制写回 (Force Write-Back): WS1 收到
Revoke后，必须将其本地的“脏”数据写回到 Petal。 - 释放 (Release): 写回完成后，WS1 通知 LS 释放锁。
- 转交 (Grant): LS 最终将（读）锁授予 WS2。WS2 从 Petal 读取，保证读到的是 WS1 刚写回的最新数据。
核心洞察： 这是一种强一致性模型。锁服务器通过“撤销”机制，充当了数据流动的指挥者，在需要时强制“脏缓存”回写到共享存储。
03. 优雅的升级：锁的双重使命——从“一致性”到“原子性”
文件系统操作（如 create, rename）是多步骤的，必须“全有或全无”。Frangipani 如何保证原子性？
它巧妙地复用了锁机制，将其升级为一种“数据库风格”的事务。这个方案几乎是“无成本”的：
- 规则： 在执行一个多步骤操作前，工作站必须获取所有需要触碰的数据的锁。在所有修改（包括写回 Petal）完成之前，一个锁都不释放。
这套机制引出了一个极其优雅的洞察——锁的双重使命：
- 对于缓存一致性（目标：可见）： 锁被用来强制可见性。
Revoke协议强制私有缓存（脏数据）被写回共享存储，从而使其对其他节点可见。 - 对于事务原子性（目标：隔离）： 锁被用来强制不可见性。通过在操作期间持有所有锁，它阻止任何其他节点访问“半成品”的中间状态，从而将其隐藏起来。
同一个工具，被用来实现两个看似完全相反的目标。这就是设计的艺术。
04. 致命的挑战：崩溃在原子操作的中途
系统现在面临最严峻的挑战：如果 WS1 在持有锁、执行原子操作的过程中崩溃了，怎么办？
- 数据处于“半成品”状态。
- 锁被永远持有，导致系统卡死。
解决方案是经典的 WAL (Write-Ahead Log) ，但 Frangipani 的实现再次展现了它的“反常”与“天才”。
Frangipani 的 WAL 设计：
- 每个工作站一份独立日志： 没有全局日志瓶颈。
- 日志存储在 Petal (共享存储) 上： 而不是本地磁盘！
第二个设计是点睛之笔。因为日志是共享的，当 WS1 崩溃时，任何一个健康的工作站（如 WS3）都可以被 LS 授权，去 Petal 上读取 WS1 的日志，并替它完成未竟的工作（“重放”日志），最后释放锁。
05. 终极难题：如何处理“过时的日志”？
一个更诡异的场景出现了：
- T1: WS1 删除文件
d/f（操作完成，锁释放）。 - T2: WS2 创建了同名文件
d/f（这是个新文件，操作完成，锁释放）。 - T3: WS1 崩溃了！
- T4: WS3 被指派恢复 WS1。它读取 WS1 的日志，发现一条“过时”的日志：“删除
d/f”。 - T5 (灾难): WS3 盲目重放日志，删除了 WS2 辛苦创建的新文件。
Frangipani 的解决方案是：版本号（Versioning）。
这是 Frangipani 设计的最后一块拼图，它将锁、日志和数据完美地绑定在一起：
- Petal 上的每一块元数据（如 inode）都有一个版本号
V（例如V=3）。 - 当 WS1 要修改它时，它必须在 WAL 中记录：“我期望的版本是
V=3，我的新版本将是V=4”。 - WS1 将新数据和新的版本号
V=4一起写入 Petal。
这个机制如何解决上述灾难？
- T1: WS1 的日志（删除）使
d/f版本变为V=4。 - T2: WS2 的日志（创建）使
d/f版本变为V=5。 - T3: WS1 崩溃。
- T4 (恢复): WS3 读到 WS1 的“过时”日志（目标版本
V=4）。 - T5 (智能恢复): WS3 在重放前检查 Petal，发现
d/f的当前版本是V=5。 - 恢复规则：
IF (Log_Version <= Petal_Version)，则说明此日志已过时，忽略它。 - 结果： WS3 看到
4 <= 5，于是安全地跳过了这条日志。WS2 的文件幸存。
更绝妙的是，这个版本号机制甚至让恢复工作站（WS3）在恢复时根本不需要获取锁，因为它仅通过比较版本号就能安全地决定是否写入，从而避免了与正常工作站的任何死锁。
