【FoundationDB 内核】运维与容量：角色资源画像

机制篇回答「事务怎么提交」；运维要回答「资源打在哪一类进程上、热点从哪来、备份与灾备保的是哪一层一致性」。本文给 角色资源画像、分片热点、备份与 DR 边界。官方 Known Limitations 中的集群规模与库体积是测试上界描述，不是给你集群的容量公式——本篇明确拒绝无来源的「每核 QPS」推算。

版本锚定：FoundationDB 7.x Administration、Backup, Restore, and Replication for Disaster Recovery、Known Limitations；角色伸缩机制见 FDB paper SIGMOD 2021 §2.3。

一、先看角色，再谈扩容

Unbundled 的运维含义是：读扩展与写扩展不是同一旋钮。

flowchart TB
  READ["Client reads"] --> SS["StorageServers shards"]
  WRITE["Client commits"] --> PX["Proxies"]
  PX --> SEQ["Sequencer versions"]
  PX --> RSV["Resolvers conflicts"]
  PX --> TL["LogServers durable"]
  TL -.->|"async pull"| SS
  CTRL["Coordinators ClusterController"]
  CTRL --> SEQ
  CTRL --> DD["DataDistributor"]
  CTRL --> RK["Ratekeeper"]

Known Limitations（官方）：性能与调优测试做到约 500 cores/processes 量级；显著更大可能出现次线性扩展。数据库键值逻辑体积测试到约 100 TB（复制与开销会使磁盘占用更高）。这些是文档中的测试边界陈述，不能改写成「你的硬件也能到」。

1.1 读写分离在容量规划上的含义

FDB paper §2.3.3 明确：客户端读直达分片 StorageServer，故读随 SS 扩展；写通过 Proxy / Resolver / LogServer 扩展。规划时至少分成两张表：

Sequencer 与 ClusterController 是逻辑单例角色：它们不是靠「加 10 个 Sequencer」扩展吞吐；Proxy 批处理与减少不必要的 epoch 切换，比复制 Sequencer 进程更符合架构。

1.2 进程与机器的放置直觉

官方 Administration 讨论机器增减与监控，但不提供通用配比。工程上可核对的约束来自复制与故障域（论文 §2.5）：同一副本组不要挤在同一故障域；TLog 需要稳定低延迟磁盘；Storage 需要容量与读带宽。具体「一机多进程」数量随 CPU 与存储引擎而变——以自身压测为准，本篇不写核比公式。

二、分片热点：机制与处置方向

2.1 读热点

官方限制写明：读会在持有副本的服务器间负载均衡，但不会自动提高热 key 的复制度。三重复制下，单个 key 或小范围的聚合读性能受限于少量存储进程的总和能力。Workaround：应用把极热数据写入多个 subspace，等效提高复制度。

2.2 写热点与冲突热点

• 单调递增键把写压到同一 shard 尾部，类似其它 range 分片系统；
• 高冲突同一 key 范围放大 Resolver 拒绝与客户端重试（第 8–9 篇）；
• Record Layer 二级索引若扇出到热前缀，会把业务写变成索引写热点（第 15 篇）。

flowchart TD
  SYM["Hot shard symptom"]
  SYM --> Q1{"Traffic on few storage processes?"}
  Q1 -->|yes| SHARD["Key design or split migrate via DataDistributor"]
  Q1 -->|no| Q2{"High not_committed conflict rate?"}
  Q2 -->|yes| CONF["Shrink txn scope or reduce contention"]
  Q2 -->|no| Q3{"Commit path CPU on proxies or TLogs?"}
  Q3 -->|yes| WRITEPATH["Scale write roles check disk on TLogs"]
  Q3 -->|no| OTHER["Network client or Ratekeeper throttling"]

DataDistributor 负责失败与均衡时的数据移动（FDB paper）；它缓解的是分布问题，不能修复「单键逻辑热点」。业务键设计仍是第一刀。

2.3 Ratekeeper

Ratekeeper 提供过载保护：在存储或事务系统压力过高时限制接入，避免雪崩。运维上应把「被限速」看成保护信号，先查 SS 延迟、TLog 持久化、冲突率，而不是立刻关闭保护。

2.4 热点与「有限读均衡」的合成效应

官方限制还指出：热 key 不会自动加副本。于是常见合成故障是——

1. 写热点把变异压到少数 Storage / 少数冲突范围；
   
2. 读热点叠在同一批 key 上，读能力卡在少数副本进程；
   
3. 客户端重试把 Proxy/TLog 打满，触发 Ratekeeper。

此时只扩 Storage 进程而不改键，往往只能短暂缓解。排障顺序见 第 17 篇：先分冲突 / 恢复 / 落后，再谈扩容。

三、备份与灾备：三层边界

官方文档区分多条路径，语义不同，不可混用同一个 RPO 故事。

flowchart LR
  subgraph logical ["Logical backup"]
    BA["backup_agent"]
    FB["fdbbackup / fdbrestore"]
    BA --- FB
  end
  subgraph dr ["Async DR"]
    DRA["dr_agent"]
    FDR["fdbdr"]
    DRA --- FDR
  end
  subgraph snap ["Disk snapshot"]
    SN["snapshot tool"]
  end

3.1 逻辑备份（backup_agent + fdbbackup / fdbrestore）

• 分布式、多 agent 协作，做一致的时间点备份，不要求停机；
• fdbbackup 控制任务；backup_agent 执行；
• 恢复时官方强调：出于安全，不会自动清空目标 key range，需人工 clear 后再 restore。

连续备份与过期（expire）用于控制备份存储增长——具体保留策略按官方 Backup 文档操作，本篇不编造保留天数。

3.2 异步灾备（fdbdr / dr_agent）

Administration：DR 通过把源集群事务异步复制到另一数据中心的目的集群；目的端始终处于与源端当前或更早状态一致的快照语义。恢复可反向复制。这与单集群内 TLog→Storage 的异步 apply 不同层级——DR 跨的是集群。

异步意味着区域级故障时可能丢失尚未复制的后缀；这是机制代价，不是实现疏忽。

3.3 磁盘快照备份

官方 Disk snapshot backup：对持久化磁盘做崩溃一致快照，恢复类似「整机掉电后重启」。无连续备份时间点选择；适合测试、合规或额外一层保护。与逻辑备份的「可选版本恢复」能力不同。

3.4 与论文中的多区域复制

FDB paper §3 描述主区域 + 卫星同步日志、跨区域异步、自动/手动 failover 等部署选项。那是产品内复制拓扑，与 fdbdr 工具文档中的「两集群异步 DR」相关但表述角度不同。运维选型时分开核对：你用的是多 region 配置，还是独立 DR 集群工具链。

3.5 三层保护对照

把「三副本」写成「已经有备份」是运维常见误解；官方 Backup 文档开篇就把副本与备份分成两层。

四、日常可观测入口（不写假输出）

本站实验台账中「status details 观察角色」在未执行前不伪造命令输出。读者应在自己的 7.x 环境实跑后对照。

4.1 扩容动作与恢复的耦合

加机器、改复制、排除进程等配置变更，在 FDB 里常常会终止当前 Sequencer 并走恢复（第 13 篇）。容量操作因此不是「纯加减进程」：

• 变更窗口要按写暂停可接受时间来排，而不是只按数据搬迁 ETA；
• 连续多次小变更可能触发多次 epoch，客户端重试叠加；
• 备份任务与大规模迁移同时进行时，先确认 Ratekeeper 与磁盘余量，避免限速与落后互相加强。

flowchart TD
  CHANGE["Config or topology change"]
  CHANGE --> EPOCH["May trigger new epoch"]
  EPOCH --> WRITEPAUSE["Commit path pause window"]
  WRITEPAUSE --> RETRY["Client retries"]
  RETRY --> OBSERVE["Watch status and error mix"]

五、学术谱系、工程间隙与开放问题

谱系：解耦存储与事务的容量独立扩展（FDB paper）→ 备份/DR 作为第二层耐久性（官方 Backup 文档）→ 与 第 13 篇 快速恢复共同构成可用性叙事。

工程间隙：论文与文档几乎不提供「每角色核数配比」的通用表；真实配比依赖工作负载是读多还是写多、冲突率、存储引擎（SSD Engine / Redwood）。把别的公司分享的核比当公式会误配。

开放问题：

1. 热 key 自动提高复制度仍是文档中的当前限制——Layer 或多 subspace 是否应产品化？
2. 逻辑备份与磁盘快照在超大规模下的窗口与成本，缺少跨部署的公开对照数据。
3. Ratekeeper 限速阈值与「用户可见 SLO」之间如何映射，仍偏经验。

六、常见误解

误解一：加机器一定线性提高提交吞吐。
读随 Storage 扩展更直接；写还受 Sequencer 批处理、Resolver 冲突、TLog 持久化与恢复频率约束。

误解二：有三副本就不需要备份。
副本防的是集群内故障；备份/DR 防的是误删、区域灾难与逻辑错误——官方 Backup 文档开篇即此分工。

误解三：可以用一条「每 GB 内存支撑 N 事务」公式做容量规划。
本系列不提供该公式；无本站实测与无官方标定方法时，容量规划只能基于自身压测与官方限制边界。

七、小结

三句话小结：

1. 运维先按角色看资源：Storage 扛读与容量，Proxy/Resolver/TLog 扛提交，Sequencer/Coordinator 扛元数据与世代，Ratekeeper 扛过载保护。
2. 热点优先改键与事务边界；DataDistributor 只能搬数据，不能消灭单键逻辑热点。
3. 逻辑备份、异步 DR、磁盘快照保护不同风险；不要混用 RPO 叙事，也不要把 Known Limitations 测试上界写成你的容量公式。

运维篇到此为止；下一篇把「延迟高了」翻译回上述机制中的具体一环。

参考资料

1. Zhou J., et al. FoundationDB…. SIGMOD 2021. §2.3 伸缩；§3 地理复制。
2. FoundationDB 7.x Administration；Backup, Restore, and Replication for Disaster Recovery；Disk snapshot backup；Known Limitations。
3. 第 11 篇 Storage Server、第 13 篇恢复、第 17 篇排障。

命令与指标名称随 Operator / 裸机部署而异；以你所安装的 7.x 文档版本为准核对面板字段。

容量规划的下一步通常是：固定一种代表性事务混合，在预发集群上做可复现压测，再对照本篇角色表解释瓶颈落点——而不是从公开博客反推核比。

无本站实测数字时，正文只保留机制边界与官方测试上界陈述。

上一篇：Record Layer：记录与二级索引
下一篇：生产排障：超时、冲突、切换、落后