分布式
校招考察频度：★ 高频（重点常考·大厂分水岭） 复习主线：分布式系统是“多台机器网络协同，对外表现得像一台机器”的复杂艺术。校招面试核心聚焦点：网络不可靠下的 CAP 定理严谨权衡（P 必选前提下 C 与 A 取舍）、BASE 理论落地、Raft 多数派共识算法两阶段提交（选主随机超时、日志复制、脑裂防范）、分布式全局唯一 ID（雪花算法 Snowflake 原理与时钟回拨排查）、一致性哈希（Consistent Hashing）与虚拟节点防数据倾斜。
分布式系统的底层共性：网络会延迟丢包、节点会宕机、时钟会漂移，唯一确定的事是“一切皆不确定”。
分类考频地图
| 专题 | 核心页面 | 校招考频星级 | 重点考查要点 |
|---|---|---|---|
| 分布式唯一 ID 与哈希 | 分布式 ID 与一致性哈希 | ★ 高频 | UUID 为什么不能做 MySQL 主键（无序导致页分裂）、Snowflake 64 位结构推导、时钟回拨三大排查解决方案、一致性哈希环与虚拟节点缓解倾斜 |
| 一致性模型与 CAP | 一致性模型与 CAP 定理 | ★ 高频 | 线性一致性（强一致）vs 因果一致性 vs 最终一致性、CAP“三选二”为何是误导（网络分区 P 必发生，关键在分区时的 C/A 抉择）、BASE 理论落地 |
| 分布式共识 Raft | Raft 共识算法深度剖析 | ☆ 中频 | 随机心跳超时破平票、多数派投票规则（任期 Term + 日志最新）、日志两阶段提交（Replicated State Machine）、选举限制与提交限制防数据丢失、网络分区脑裂数学推导 |
| 共识协议族谱 | Paxos 与 ZAB 协议 | 低频 | Basic Paxos 两阶段流程、Multi-Paxos 选主、ZooKeeper 的 ZAB 协议（崩溃恢复 + 原子广播）、epoch 纪元号防老 Leader 捣乱 |
分布式三大挑战
| 挑战 | 说明 |
|---|---|
| 网络不可靠 | 延迟、丢包、分区（唯一确定的事是”不确定”） |
| 时钟不一致 | 各机器时钟漂移（不能用本地时间排序） |
| 状态分散 | 无共享内存，一致性靠协议 |
CAP 定理
CAP: 三选二, 但 P 是必选
- C（一致性）：所有节点同时看到相同数据
- A（可用性）：请求总能得到响应（不保证数据最新）
- P（分区容错）：网络分区时系统仍工作
核心认知：网络分区必然发生，P 必须选。分区时在 C 和 A 之间二选一：
- CP：分区时拒绝服务保一致（etcd、ZooKeeper）
- AP：分区时继续服务，恢复后合并（Cassandra、DNS）
面试话术：“CAP 三选二”是误导，正确说法是分区时 C/A 二选一（无分区时三者可兼得）。
BASE
- Basically Available：基本可用（降级、限流）
- Soft state：状态可临时不一致
- Eventually consistent：最终一致
BASE 是 AP 路线的工程化：用最终一致换可用性。典型：缓存 + 数据库（见缓存一致性篇）、异步消息（见 MQ 篇）。
本分组地图
- 一致性模型：从强到弱的谱系
- Raft / Paxos / ZAB：共识协议
- 分布式 ID 与哈希：基础组件
面试追问
- CAP 是什么？ 一致性、可用性、分区容错。分区必选，分区时 C/A 二选一
- CP 和 AP 例子？ CP：etcd/ZK（分区拒写保一致）；AP：Cassandra/DNS（分区继续服务）
- BASE 是什么？ 基本可用 + 软状态 + 最终一致。AP 路线的工程实践
- 为什么 P 必选？ 网络分区无法避免（不是”如果”是”何时”）。不选 P 的分布式不存在
- 最终一致怎么实现？ 异步复制 + 重试 + 补偿（消息队列、对账）。见各篇