【FoundationDB 内核】Unbundled 全景:事务、日志与存储为何拆开
以 SIGMOD 2021 为锚点,厘清 FoundationDB 控制面与数据面角色分工,说明一次事务穿过 Proxy、Sequencer、Resolver、TLog、Storage 的路径,并与站内 distributed/39、tikv-htap 划清边界。
发布来自土法炼钢兴趣小组的知识、笔记、进展和应用。主题包括数据结构和算法、编程语言、网络安全、密码学等。
共 7 篇文章 · 返回首页
以 SIGMOD 2021 为锚点,厘清 FoundationDB 控制面与数据面角色分工,说明一次事务穿过 Proxy、Sequencer、Resolver、TLog、Storage 的路径,并与站内 distributed/39、tikv-htap 划清边界。
用一张读写总图串联 FoundationDB 各角色,标明哪些可水平扩展、哪些是逻辑单例,并与 TiKV 多组件分离作机制对照。
说明 Sequencer 如何分配 read version 与 commit version、为何是逻辑单点而非无高可用,以及世代恢复如何与版本推进衔接。
钉住 FoundationDB 一次写事务的提交路径:Client 经 Commit Proxy 取 commit version、Resolver 做 OCC、TLog 多数持久化后才向客户端返回成功;并划清「提交成功」与「Storage Server 可读」之间的边界。
按 SIGMOD 2021 钉住 FoundationDB 把失败收敛到同一条恢复路径:Sequencer 锁定 Coordinator、停止旧 LogServer、招募新 Proxy/Resolver/TLog、确定 RV/PEV,并说明写暂停、读边界与旧角色隔离。
用症状到机制的决策树排查四类高频问题:事务超时、冲突风暴、Sequencer 切换写暂停、Storage 落后于 TLog;回链 OCC、恢复与运维篇,不重复调参手册。
补齐 FoundationDB 选型叙事与生产内核之间的一层:拆解 Proxy、Sequencer、Resolver、TLog、Storage Server 的 Unbundled 写路径,严格可串行化、Redwood 与确定性模拟,并以 Record Layer 和 TiKV/etcd 对照收束。