• Coordinators

所有客户端和服务器都使用群集文件连接到FoundationDB群集，该群集文件包含协调程序的IP：PORT。客户端和服务器都使用协调器与集群控制器连接。如果不存在，服务器将尝试成为集群控制器，并在选出一个后向集群控制器注册。客户端使用集群控制器来保持最新的代理列表。

• 集群控制器

集群控制器是由大多数协调器选出的单例。它是集群中所有进程的入口点。它负责确定进程何时失败，告诉进程它们应该成为哪些角色，并在所有进程之间传递系统信息。

• Master

master 负责协调 write 子系统从一代到下一代的过渡。写入子系统包括主、代理、解析器和事务日志。这三个角色被视为一个单位，如果其中任何一个失败，我们将招募所有三个角色的替代者。master 为代理提供批量突变的提交版本。

历史上，Ratekeeper 和 Data Distributor 与 Master 耦合在同一进程上。从 6.2 开始，两者都成为集群中的单例。生命时间不再与师父绑定。

• 代理

代理负责提供读取版本、提交事务并跟踪负责每个密钥范围的存储服务器。为了提供读取版本，代理将要求所有其他代理查看此时最大的已提交版本，同时检查事务日志是否未停止。Ratekeeper将人为地降低代理提供读取版本的速度。

提交是通过以下方式完成的：

• 从 master 获取提交版本。
• 使用解析器确定事务是否与先前提交的事务冲突。
• 使事务在事务日志上持久化。

以\xff字节开头的密钥空间是为系统元数据保留的。提交到该密钥空间的所有变更都通过解析器分发给所有代理。该元数据包括键范围和具有该范围键数据的存储服务器之间的映射。代理按需向客户提供此信息。客户端缓存这个映射；如果他们向存储服务器询问它没有的密钥，他们将清除缓存并从代理获取更新的服务器列表。

• 事务日志

事务日志使更改持久化到磁盘以实现快速提交延迟。日志按版本顺序从代理接收提交，并且只有在数据被写入并同步到磁盘上的仅附加突变日志后才响应代理。在数据甚至写入磁盘之前，我们将其转发到负责该突变的存储服务器。一旦存储服务器使突变持久化，它们就会从日志中弹出它。这通常发生在最初将突变提交到日志后大约 6 秒。我们只在进程重新启动时从日志的磁盘中读取。如果存储服务器发生故障，则绑定到该存储服务器的突变将在日志中累积。

• 解析器

解析程序负责确定事务之间的冲突。如果事务读取在事务的读取版本和提交版本之间写入的键，则事务会发生冲突。解析器通过在内存中保存最后 5 秒提交的写入，并将新事务的读取与这组提交进行比较来做到这一点。

• 存储服务器

集群中的绝大多数进程都是存储服务器。存储服务器被分配了密钥范围，并负责存储该范围内的所有数据。他们在内存中保留 5 秒的突变，并在 5 秒前保留数据的磁盘副本。客户端必须在最后 5 秒内读取一个版本，否则会 transaction_too_old出错。SSD 存储引擎将数据存储在基于 SQLite 的 B 树中。内存存储引擎将数据存储在内存中，并带有仅在进程重新启动时从磁盘读取的附加日志。在即将发布的 FoundationDB 7.0 版本中，B-tree 存储引擎将被全新的Redwood 引擎取代。

• 数据分发器

数据分配器管理存储服务器的生命周期，决定哪个存储服务器负责哪个数据范围，并确保数据在所有存储服务器 (SS) 上均匀分布。数据分发器作为集群中的单例由集群控制器招募和监控。

• 监控系统

Ratekeeper 监控系统负载并在集群接近饱和时通过降低代理提供读取版本的速率来降低客户端事务速率。Ratekeeper 作为集群中的单例，由 Cluster Controller 招募和监控。

• 客户

客户端与特定语言绑定（即客户端库）链接，以便与 FoundationDB 集群通信。语言绑定支持加载多个版本的 C 库，允许客户端与旧版本的 FoundationDB 集群通信。目前，官方支持 C、Go、Python、Java、Ruby 绑定。