【FoundationDB 内核】Sequencer：read/commit version、逻辑单点与恢复
内容提要
FoundationDB通过Sequencer管理事务版本分配，确保严格可串行化。每个世代只有一个活跃的Sequencer，故障时可快速恢复。客户端通过Proxy间接使用Sequencer，需短事务和幂等性以应对版本作废问题。
关键要点
-
FoundationDB通过Sequencer管理事务版本分配，确保严格可串行化。
-
每个世代只有一个活跃的Sequencer，故障时可快速恢复。
-
客户端通过Proxy间接使用Sequencer，需短事务和幂等性以应对版本作废问题。
-
Sequencer发放的commit version是序列化顺序和日志序号的来源。
-
Sequencer与Proxy协作，避免客户端直接连接单点，减少连接爆炸。
-
恢复过程中，新Sequencer从旧配置中锁定状态，确保事务一致性。
-
逻辑单点Sequencer并不意味着没有高可用性，短MTTR是关键。
-
版本租约和5秒窗口限制确保了事务的可恢复性和冲突管理。
延伸解读
Sequencer的高可用性
尽管FoundationDB的Sequencer是逻辑单点，但其设计确保了高可用性。每个世代只有一个活跃的Sequencer，故障时可以迅速恢复，依赖于短的平均恢复时间（MTTR）。这种机制使得系统在面对故障时能够保持稳定性，而不是依赖多个Sequencer同时发号。
事务设计的注意事项
在使用FoundationDB时，开发者需要注意事务的长度和幂等性。由于恢复过程中可能导致旧版本作废，应用应设计为短事务并支持幂等重试，以确保在故障恢复时不会出现不确定的提交结果。这种设计可以有效降低因长事务导致的冲突和恢复复杂性。
版本管理的复杂性
FoundationDB的版本管理机制通过Sequencer发放read version和commit version，确保事务的严格可串行化。然而，开发者需理解版本的推进与冲突检测并不在Sequencer上进行，而是由Resolver负责。这意味着在设计数据模型时，需考虑如何减少读写冲突，以优化系统性能。
延伸问答
FoundationDB中的Sequencer是什么？
Sequencer是FoundationDB中用于管理事务版本分配的组件，确保事务的严格可串行化。
如何确保FoundationDB的高可用性？
FoundationDB通过短的MTTR和故障后整代恢复来确保高可用性，而不是依赖多个活跃的Sequencer。
客户端如何与Sequencer交互？
客户端通过Proxy间接与Sequencer交互，Proxy负责获取read version和提交commit version。
Sequencer在事务提交中扮演什么角色？
Sequencer发放commit version，定义事务的序列化顺序，并确保事务的一致性。
什么是版本租约，它如何影响事务？
版本租约确保commit version单调递增，并限制read version的历史，影响事务的可恢复性和冲突管理。
FoundationDB如何处理故障恢复？
在故障恢复时，新Sequencer从旧配置中锁定状态，确保事务一致性，并快速恢复服务。
