L3 · RPC · 放置 · EC · Raft
走向分布式
单机引擎复制三份还不是分布式系统。成员管理、数据放置、纠删码、共识 —— 你运维时对付过的每种故障,现在要在代码里给出答案。
本阶段出口:里程碑③ forge-cluster:3 节点对象存储,EC 条带落盘,掉任意一个节点读写不中断。
6 节课 · 约 5 小时已完成 0/6
- 1
网络与 RPC:tonic/gRPC
编码50m节点之间怎么说话?用 protobuf 定义 forge 的内部协议,tonic 生成服务骨架,顺便搞懂连接池、超时与重试的正确姿势。
- 用 protobuf 定义 put/get/gossip 协议并保持向后兼容
- 实现带超时与重试的客户端,理解幂等性前提
- 解释 HTTP/2 多路复用对存储流量的利弊
- 2
集群成员与故障检测
编码50m「节点挂了」在代码里是什么?心跳、超时、误判 —— 实现基于 gossip 的成员列表,理解为什么故障检测永远不可能完美。
- 实现心跳与 phi accrual 风格的故障判定
- 解释脑裂场景与为什么需要仲裁
- 设计节点状态机:alive / suspect / dead / rejoin
- 3
数据放置:一致性哈希、CRUSH 与 Weka bucket
编码55m对象该放哪个节点?三大流派对比着实现:一致性哈希环、CRUSH 伪随机树、Weka 的 bucket 切分。加减节点时谁搬的数据最少?
- 实现带虚拟节点的一致性哈希环
- 解释 CRUSH 与哈希环在故障域约束上的差别
- 说清 Weka bucket 模型为什么利于元数据扩展
- 4
复制与纠删码
编码55m三副本太贵,EC 便宜但重建时要算。用 reed-solomon crate 实现 4+2 条带,写路径同时落 6 个分片,读路径缺 2 个也能拼回来。
- 解释 RS 码的直觉:多项式插值,不用推公式
- 实现 4+2 条带的编码、解码与部分读
- 算清 EC 在小 IO 下的读改写代价
- 5
Raft:给元数据上共识
编码60m放置表、成员列表这些「集群真相」必须所有节点认同。理解 Raft 的选举与日志复制,用 openraft 存管 forge 的集群元数据。
- 讲清 Raft 选举、日志复制、提交点推进的流程
- 基于 openraft 实现集群配置状态机
- 解释为什么数据面不走 Raft、只有元数据走
- 6
里程碑③:拔掉一个节点
里程碑50m3 节点集群持续读写,当场 kill 掉一个节点:写入不中断、已有数据全能读、节点回归后自动补齐。用你熟悉的运维手法验收自己的系统。
- 编排三节点故障演练脚本并全部通过
- 观测故障切换期间的延迟毛刺并解释来源
- 写出运维手册第一版:部署、扩容、换盘