> 本文是写作规划，不是可发布正文。拆解对象：FoundationDB 7.x 的 Unbundled 架构、OCC 严格可串行化、Log / Storage 分离、Redwood 与确定性模拟；Record Layer 只作一篇边界章。不重写 [distributed/39](../../distributed/39…

本文记录了FoundationDB内核的单机实验，涵盖事务冲突与重试、状态观察、事务时间限制及进程重启后的状态恢复。建议在Linux或WSL2环境中进行实验，并确保Python绑定与API版本一致。

FoundationDB 采用控制面与数据面分离的架构，支持独立扩展。事务处理流程包括获取读版本、提交、冲突检测及日志持久化。本文为系列第一篇，介绍了角色分工及事务路径。

本文讨论了FoundationDB的事务处理机制，重点介绍了@transactional函数的使用、冲突检测、自动重试及5秒事务限制。事务在客户端缓冲写入，提交时检查读写冲突，读过的key会影响冲突范围。事务需在5秒内完成，超时将导致失败。文章强调了幂等性的重要性，以确保重试时结果的一致性。

本文讨论了FoundationDB中Coordinators和Cluster Controller的角色与功能。Coordinators通过集群文件提供配置权威，持久化事务系统配置；而Cluster Controller负责角色招募和系统状态维护。Paxos协议用于确保配置一致性，但用户数据不存储在Coordinators上。文章强调了Coordinators与数据存储的区别及系统故障时的恢复机制。

本文讨论了FoundationDB的Proxy层，包括Grv Proxy和Commit Proxy的角色与功能。Grv Proxy负责发放读版本并检查日志存活，Commit Proxy处理事务提交和冲突检测。通过拆分这两个角色，系统能够更好地扩展和优化性能。Ratekeeper控制读版本的发放速率，以防止过载，从而提高事务处理的效率和安全性。

本文讨论了FoundationDB的读写数据流和角色拓扑，强调了扩展性与单点故障的边界。读路径通过Grv Proxy获取版本，写路径由Commit Proxy协调。文章还对比了FoundationDB与TiKV在组件分离、扩展和排障策略上的不同，最后强调了监控和容量规划的重要性，以确保系统健康运行。

FoundationDB通过Sequencer管理事务版本分配，确保严格可串行化。每个世代只有一个活跃的Sequencer，故障时可快速恢复。客户端通过Proxy间接使用Sequencer，需短事务和幂等性以应对版本作废问题。

本文讨论了FoundationDB的写事务提交过程，强调提交成功与数据可见性之间的区别。提交由Commit Proxy协调，涉及Sequencer、Resolver和TLog。客户端在提交后依赖TLog的耐久性，但Storage Server的可读性可能会延迟。文章还探讨了批处理、冲突检测及与TiKV的对比，指出了系统设计选择和潜在的工程挑战。

本文讨论了FoundationDB中的事务冲突检测机制，重点在于Resolver如何判断并发事务的冲突。系统通过跟踪每个事务的读写范围，若发现读过的值在提交前被其他事务修改，则该事务会失败。Resolver保留最近5秒的写历史以进行冲突检测，确保高效并行处理。文章还探讨了通过调整读集和使用原子操作来减少冲突，以及客户端在事务冲突时的自动重试机制。

本文讨论了FoundationDB的严格可串行化和外部一致性，强调了5秒事务限制的设计目的，以确保系统恢复的有界性。通过结合OCC与MVCC，FoundationDB实现了可串行化快照隔离（SSI）语义。在高冲突情况下，重试机制可能导致吞吐量下降，需通过优化数据模型和减少读集来缓解。

本文讨论了FoundationDB中的TLog（事务日志）机制，强调其在客户端提交中的重要性。TLog通过将变更日志复制到多个LogServer来确保数据持久性，提交成功的条件是所有指定副本的日志都持久化。文章还探讨了Durable Version（DV）和Known Committed Version（KCV）的概念，以及在恢复过程中确保已承诺事务可找回的方法。TLog的设计使存储与提交路径解耦，提高了I/O效率，但可能导致短暂的读延迟。

本文讨论了FoundationDB的存储架构，重点在于客户端如何直接读取Storage Server，绕过Proxy和Resolver。每个Storage Server管理多个shard，支持异步复制。客户端通过缓存的元数据定位数据，并在5秒内读取版本。文章还探讨了数据迁移、负载均衡机制，以及读路径设计如何提高性能和一致性。

本文探讨了FoundationDB的存储引擎，重点比较了Redwood与SQLite派生引擎的区别。Redwood通过多版本B-Tree和前缀压缩技术，提高了吞吐量并降低了写放大。文章指出，存储引擎的选择不会影响分布式事务的隔离性，且引擎切换需谨慎。整体而言，Redwood在设计上弥补了SQLite引擎的不足，适应了更复杂的工作负载需求。

本文讨论了FoundationDB的故障恢复机制，强调将故障视为常态并快速恢复。通过角色招募、epoch管理和版本控制，确保事务系统的高可用性。恢复过程包括锁定状态、停止旧角色、招募新角色，并计算恢复版本（RV）和上一epoch版本（PEV）。恢复期间写路径不可用，但读路径可访问已有数据。整体目标是缩短恢复时间，提高系统稳定性。

本文讨论了FoundationDB的确定性模拟测试，重点在于通过模拟器测试网络、磁盘、时钟和随机数接口。模拟器使用事件队列驱动，确保恢复路径的可重放性。通过故障注入和Buggify技术，验证系统在故障情况下的恢复能力。文章强调模拟测试与生产环境的差异，以及其在确保数据一致性和恢复能力方面的重要性。

FoundationDB的Record Layer提供有序、事务性的键值API，支持结构化记录和二级索引。通过Protocol Buffers定义记录类型，使用Tuple和Subspace隔离逻辑数据库。二级索引与主记录在同一事务中维护，确保一致性。CloudKit利用Record Layer实现多租户结构化存储，提供强一致性和丰富API，整体设计强调事务性和高并发性能优化。

本文讨论了FoundationDB的运维机制，包括事务提交、资源分配、备份与灾备等。强调了读写分离、角色扩展和热点处理的重要性，并指出加机器不一定线性提升吞吐的常见误解。备份方式包括逻辑备份、异步灾备和磁盘快照，分别防范不同风险。运维需关注角色资源，合理规划容量，避免混淆副本与备份的功能。

本文讨论了FoundationDB中的高频问题及其决策树，包括事务超时、冲突风暴、Sequencer切换和Storage落后。针对每种问题，提供了症状、机制和处理建议，强调了事务大小和时间限制的重要性，以及有效排障的方法。建议在故障排查时结合模拟和容量规划，以确保系统稳定性。

本文总结了分布式KV系统的选型决策树，涵盖etcd、FoundationDB、TiKV等的适用场景与机制，强调了严格可串行化、事务处理和存储解耦等关键概念，并指出了高冲突负载下OCC重试的可接受性等开放问题。