共识问题
多节点对 同一序列操作 达成一致。Paxos 难懂；Raft 可理解性优先，面试主流。
Raft 角色
- Leader：处理写、复制 log
- Follower：被动接收
- Candidate：选举中
安全性
已 commit 的 entry 不会丢（多数派原则）。新 leader 必含所有已提交 log（投票限制）。
与业务
Kafka controller、Redis Sentinel 选主思想类似但实现不同。强一致配置 用 etcd：
服务启动 → 注册 /services/payment/instance-1
配置变更 → Watch 热更新
分布式锁 → lease + compare-and-swapZooKeeper vs etcd
ZK ZAB 协议，临时顺序节点做锁；etcd gRPC + Raft，K8s 默认存储。ZK 读多写少；etcd 云原生。
分布式锁注意
fence token 防旧锁持有者写入；锁需 TTL + 续租；Redlock 争议：需理解时钟与 GC 停顿。
与 CAP
Raft 集群 CP：少数派分区不可写，保证一致。
面试
口述一次写请求在 Raft 中的路径；leader 宕机选举时间（election timeout 随机）。week07-microservices-design 讲注册中心用法。
实战巩固与面试表达
本篇属于 8 周冲刺 week07-raft-distributed 主题。复习时先闭卷回答 frontmatter 中三张 flashcard，再展开口述两个「为什么」：为什么这种方案能 work、边界失败时如何降级。与相邻章节对照：算法篇强调复杂度与模板，Go 篇强调工程默认写法，中间件篇强调线上故障案例。
动手与自检清单
用 25 分钟限时做 1 道相关练习题或画出一张架构/数据结构示意图；用 5 分钟写 STAR 片段说明你在项目里是否用过类似技术。记录 3 个面试追问及你的标准答法，存入 /zh/notebook/master-plan 笔记。若某点不熟，回到对应 /chapters 交互 Lab 重新走一遍流程，比死记卡片更有效。
易错点提醒
避免只背名词不会画图；避免只说优点不谈 trade-off（性能、一致性、运维成本至少提一项）；避免把学习 Demo 说成百万 QPS 生产。回答时使用「场景 → 方案 → 结果 → 反思」四段式，体现工程成熟度。
补充要点
脑裂靠 term 与 quorum；日志 compaction snapshot 安装。etcd lease 租约续期做锁；watch 推送配置变更。
自检
对比 Raft 与 MySQL 半同步复制；画图 follower 落后合并 log。