【FoundationDB 内核】确定性模拟：FDB 的工程落点

分布式百科：确定性模拟测试 已经讲清：控制网络、磁盘、时钟与随机数，执行就变成「种子 → 路径」的可重放函数。本篇不重复那套通识，只回答 FoundationDB 内核读者的问题：这些接口在 FDB 里接到哪、如何覆盖第 13 篇的恢复路径、和生产二进制差在哪。

版本锚定：FDB paper SIGMOD 2021 §4 Simulation Testing；FoundationDB 源码中的 flow/、fdbrpc/、模拟器与 Buggify 机制；7.x 构建与测试入口以官方仓库当前文档为准。

一、与 distributed/54 的分工

读完 54 再读本篇，可以少走「又学一遍 DST」的弯路；若只关心 FDB，本篇自洽，但遇到「为什么不能直接调 clock_gettime」时应回链 54。

二、接口替换：网络、磁盘、时钟、随机数

FDB paper Figure 6 把模拟器画成：同一套数据库代码，所有非确定性与通信被抽象；生产实现是对系统调用的薄封装，模拟实现由离散事件调度器驱动。

flowchart TB
  APP["FDB server logic in Flow actors"]
  APP --> ABS["Abstraction: network disk time RNG"]
  ABS --> PROD["Production shim to OS syscalls"]
  ABS --> SIM["Simulator: deterministic event queue"]
  SIM --> NET["Simulated network delay drop partition"]
  SIM --> DISK["Simulated disk partial write reboot"]
  SIM --> CLK["Logical clock fast-forward"]
  SIM --> RNG["Seeded PRNG"]

2.1 Flow：把并发收进可调度 actor

FoundationDB 服务端主要用 Flow（C++ 上的 async/await 风格扩展）编写。Actor 由 Flow 运行时调度；刻意避免多线程抢占式并发污染确定性。FDB paper 写明：数据库代码本身确定，一个节点通常对应一个进程/核，而不是共享地址空间里的多线程竞态。

对恢复路径的含义：第 13 篇里的「停止旧 TLog → 招募新角色 → 写 Coordinator」是一串 actor 与 RPC，在模拟里变成事件队列上的确定顺序，而不是「看机器当天忙不忙」。

2.2 网络（fdbrpc 路径）

生产：真实套接字。
模拟：进程内消息传递；延迟、丢包、乱序、分区由种子驱动。恢复测试可以稳定构造「旧 LogServer 应答子集刚好过复制度门槛」或「ClusterController 与 Sequencer 之间的分区」。

2.3 磁盘

生产：文件系统与 fsync 语义。
模拟：可注入写入失败、部分写、机器重启后只保留已同步数据。这对 TLog 持久化与「DV 是否前进」直接相关——RV 计算依赖 DV/KCV，磁盘故障注入是恢复正确性的主战场之一。

2.4 时钟

生产：系统时钟。
模拟：逻辑时钟，可快进到下一事件。低 CPU 利用率段不必真的睡过去，因此「数秒级恢复 + 长空闲」类 bug 的发现效率高于墙钟集成测试（论文定性论述）。

2.5 随机数

选举超时、退避、负载均衡抖动等统一走种子化 PRNG。同一种子 + 同一代码版本 ⇒ 同一事件序；CI 报出的种子就是回归用例 ID。

三、模拟器里跑什么：整集群与可组合 workload

模拟器在单进程里拉起多个逻辑 FDB 服务器，经模拟网络互连，并挂上可组合的 workload：

• 故障注入指令（机器/机架/数据中心级停机与重启）；
• 模拟业务读写；
• 数据库配置变更（与第 13 篇「配置变更也走恢复」同路径）；
• 直接调用内部功能点。

flowchart LR
  SEED["Seed"] --> SWARM["Swarm: cluster size config workloads faults"]
  SWARM --> RUN["One simulation run"]
  RUN --> ORACLE["Oracles: asserts contracts recoverability"]
  ORACLE -->|fail| REPLAY["Replay same seed"]
  ORACLE -->|pass| NEXT["Next seed"]

测试预言（oracle）不只看「没崩溃」：

• workload 内断言检查原子性/隔离性可维护的数据不变量；
• 代码内本地断言；
• 可恢复性：把环境推到足以破坏可用性的故障组合后，再恢复到应可恢复的状态，断言集群最终恢复（FDB paper §4）。

这直接钉住第 13 篇的产品命题：失败被设计成走恢复，因此模拟必须反复走恢复，而不是只测 steady-state 提交。

四、Buggify 与恢复路径覆盖

外部故障注入改变网络与机器；Buggify 在代码内部关键决策点引入「不违约但罕见」的行为：故意延迟、返回通常成功的错误、选怪异调参等。生产构建中编译为无开销；模拟构建由 PRNG 触发。

对恢复相关代码的工程意义：

论文强调：调参随机化还防止「某一组性能参数偶然变成正确性依赖」。恢复逻辑若依赖隐式超时窗口，会在模拟里被不同种子拆穿。

五、种子重放工作流（FDB 工程视角）

与 54 篇通识示例相同，但落到 FDB 仓库习惯：

1. CI / 本地跑模拟，某种子触发断言或不可恢复。
2. 用同一种子重跑；事件序对齐后下断点或加日志。
3. 修复后再次同种子确认；种子进入回归集。
4. 大版本前可并行放大种子扫描（论文描述为可突发扩容的 embarrassingly parallel 测试）。

sequenceDiagram
  participant CI as CI swarm
  participant DEV as Developer
  participant SIM as FDB simulator

  CI->>SIM: Run seed S
  SIM-->>CI: Assert fail at recovery step
  CI-->>DEV: Report seed S
  DEV->>SIM: Replay seed S
  SIM-->>DEV: Same event order
  DEV->>SIM: Fix and replay seed S
  SIM-->>DEV: Pass
  DEV->>CI: Keep seed S in regression

本站不引用未经核对的「每天百万模拟小时」营销口径作为硬指标；FDB paper 对离散事件快进与并行种子扫描的机制描述是 A 级依据，具体产能数字以论文原文表述为准，不在此改写。

六、能测到什么、测不到什么

6.1 擅长

• 第 13 篇的 epoch 切换、旧 TLog 停止、RV/PEV 计算相关竞态；
• 复制与故障域约束下的数据丢失边界（与论文 §2.5 策略相关的场景）；
• 客户端可见的严格可串行化契约在故障交叉下是否被破坏（通过 workload 不变量）。

6.2 边界（工程间隙）

确定性模拟不替代形式化验证，也不替代生产渐进发布；它与 第 17 篇 的症状树互补：模拟缩小「正确性」空间，排障处理「已部署配置与负载」空间。

6.3 与角色恢复测试的具体映射

把第 13 篇步骤映射到模拟手段，便于读源码或加 workload 时对号入座：

flowchart TD
  W["Recovery workload"]
  W --> F1["Inject TLog subset silence"]
  W --> F2["Inject Sequencer kill"]
  W --> F3["Inject disk partial write"]
  F1 --> O["Oracle: no dual epoch commits"]
  F2 --> O
  F3 --> O
  O --> INV["App invariant holds after retries"]

若某次改动触及 fdbserver 恢复相关 actor，仅跑「无故障提交」回归不够；至少应用能触发上表若干行的种子或 workload 组合。具体命令以仓库当前测试文档为准，本篇不伪造 CI 输出。

七、学术谱系与开放问题

谱系：分布式系统可重放测试的工程传统 → FoundationDB 将 DST 做成产品正确性主路径（Wilson, Strange Loop 2014 演讲为 B 级口述；机制以 SIGMOD 2021 §4 为准）→ TigerBeetle 等用现代语言复现同一抽象（见 distributed/54）。

争论：DST 与模型检测/TLA+ 谁覆盖哪类 bug——社区共识是互补而非替代；FDB 选择「真实代码 + 模拟世界」换取与生产二进制同构，代价是必须维持 Flow/抽象层纪律。

开放问题：

1. 如何系统度量「恢复相关状态空间」覆盖率，而不仅是 TEST() 点计数？
2. 模拟与云盘/多租户存储语义之间的模型缺口，如何在不破坏确定性的前提下缩小？
3. 开源贡献者变更恢复路径时，最小必跑种子集如何维护才不依赖内部 swarm 规模？

八、常见误解

误解一：读过 DST 通识就等于理解 FDB 恢复已被测全。
通识说明方法；FDB 是否覆盖某条恢复分支，取决于 workload、故障分布与 Buggify 点是否踩到——要看模拟配置与覆盖宏，不是方法论标题。

误解二：模拟通过等于生产延迟达标。
模拟验证契约与恢复；延迟与容量见 第 16 篇，且需真实负载，不能把模拟快进当成性能证明。

误解三：Buggify 是外部混沌工程工具。
它是编译进代码的白盒变异；与外部故障注入叠加，而不是替换。

九、小结

三句话小结：

1. FDB 用 Flow 把服务端收进可替换的网络/磁盘/时钟/RNG 抽象；生产走系统调用，模拟走种子驱动的事件队列。
2. 模拟器跑整集群逻辑与可组合 workload，用断言与可恢复性 oracle 反复锤第 13 篇的 epoch 恢复，而不是只测无故障提交。
3. Buggify + swarm + 种子回归构成工程闭环；DST 不给出吞吐排名，也不取消生产可观测与排障。

参考资料

核心论文 / 文档

1. Zhou J., et al. FoundationDB…. SIGMOD 2021. §4 Simulation Testing.
2. FoundationDB 官方开发与测试文档；源码 flow/、fdbrpc/、simulator 相关路径。

站内联动

3. 确定性模拟测试通识
4. 第 13 篇故障恢复
5. 第 17 篇生产排障

辅助（B 级）

6. Will Wilson. Testing Distributed Systems w/ Deterministic Simulation. Strange Loop 2014.（口述历史与动机；机制细节以论文与源码为准）

上一篇：故障恢复：角色招募与恢复 epoch
下一篇：Record Layer：记录与二级索引