分布式挑战
网络延迟、丢包、节点故障不可避免。单机事务 ACID 无法直接套多节点，需一致性模型与协调协议。
CAP
- C Consistency：所有节点同一时刻看到相同数据（线性一致视角）。
- A Availability：每个请求得到非错误响应（不保证最新）。
- P Partition tolerance：网络分区仍运行。
一致性谱系
| 级别 | 说明 | |------|------| | 强一致 | 写后读立即可见 | | 因果一致 | 有因果关系的操作有序 | | 最终一致 | 收敛到相同，中间不一致 |
MySQL 主从 异步复制 是最终一致；读主强一致。
BASE 与业务
促销库存可短暂超卖再补偿（业务层）；账户余额需强一致或分布式事务（Seata、2PC 慎用）。
PACELC 扩展
无分区时在 Latency 与 Consistency 间权衡：Cosmos 可调、Dynamo 可调 QUORUM。
与 Week 5/6 联系
- Redis 主从延迟 → 最终一致读。
- Kafka ISR ack → 一致性与可用折中。
week07-raft-distributed讲如何实现共识。
面试答题
不要背「CAP 三选二」口号；说 分区下具体行为：返回错误 vs 返回旧值，如何监控与补偿。
实战巩固与面试表达
本篇属于 8 周冲刺 week07-cap-consistency 主题。复习时先闭卷回答 frontmatter 中三张 flashcard，再展开口述两个「为什么」：为什么这种方案能 work、边界失败时如何降级。与相邻章节对照：算法篇强调复杂度与模板，Go 篇强调工程默认写法，中间件篇强调线上故障案例。
动手与自检清单
用 25 分钟限时做 1 道相关练习题或画出一张架构/数据结构示意图；用 5 分钟写 STAR 片段说明你在项目里是否用过类似技术。记录 3 个面试追问及你的标准答法，存入 /zh/notebook/master-plan 笔记。若某点不熟，回到对应 /chapters 交互 Lab 重新走一遍流程，比死记卡片更有效。
易错点提醒
避免只背名词不会画图；避免只说优点不谈 trade-off（性能、一致性、运维成本至少提一项）；避免把学习 Demo 说成百万 QPS 生产。回答时使用「场景 → 方案 → 结果 → 反思」四段式，体现工程成熟度。
自检
设计跨机房用户配置：选 AP 还是 CP？说明理由。下一篇：Raft。