一、CAP 定理：分布式系统的不可能三角
1. 核心定义
CAP 定理由 Eric Brewer 提出，2002 年被数学证明，核心结论是：分布式系统中，一致性（C）、可用性（A）、分区容忍性（P）无法同时满足，最多只能满足其中两项。
2. 三大特性拆解
表格
| 特性 | 精准定义 | 核心诉求 | 典型场景 |
|---|---|---|---|
| 一致性（C） | 所有节点同一时间看到相同数据，写操作完成后，后续所有读均返回最新值（线性一致性） | 数据绝对正确 | 银行转账、核心账务、支付交易 |
| 可用性（A） | 非故障节点在合理时间内返回有效响应，不报错、不超时 | 服务持续可用 | 电商商品页、公共服务接口 |
| 分区容忍性（P） | 网络分区（节点间通信中断）发生时，系统仍能继续工作 | 系统容错能力 | 跨地域集群、多机房部署 |
3. 实际选型原则
- 必须满足 P ：分布式系统网络分区不可避免，因此实际选型是 C 和 A 的二选一。
- CP 架构 ：牺牲可用性，保证强一致性。适合金融交易、核心数据同步场景，代表：ZooKeeper、etcd。
- AP 架构 ：牺牲一致性，保证高可用。适合电商推荐、日志收集等对实时性要求低的场景，代表：Cassandra、Eureka。
4. 延伸：BASE 理论
CAP 理论的落地补充，核心是 基本可用、软状态、最终一致性：
- 基本可用（Basically Available）：故障时损失部分功能，核心服务可用（如秒杀系统降级为排队）。
- 软状态（Soft State）：允许数据副本同步存在延迟，状态可临时不一致。
- 最终一致性（Eventually Consistent）：延迟一段时间后，所有副本数据最终一致。
二、etcd：云原生分布式键值存储
1. 核心定位
etcd 是 高可用、强一致性分布式键值存储 ，用 Go 语言开发，基于 Raft 共识算法，核心用途是共享配置、服务发现、集群协调，是 Kubernetes 的核心存储组件。
2. 核心特性
- 强一致性：基于 Raft 算法，保证线性一致性，写后读可获取最新数据。
- 高可用：3/5/7 节点集群（奇数），少数节点宕机不影响整体服务。
- 数据模型 ：扁平键值结构，支持前缀查询，用
/模拟层级（如/app/config）。 - 持久化：WAL（预写日志）+ 快照机制，数据不丢失。
- 核心机制 ：
- Lease（租约）：给键设 TTL，客户端需定期续租，宕机后键自动删除，实现服务健康检查。
- Watch（监听）：实时监听键 / 前缀变更，主动推送通知，替代轮询。
- 原子操作：支持 CAS（Compare-and-Swap），保证并发安全。
3. 核心应用场景
- 服务发现：微服务 / 容器实例注册地址，其他服务通过 Watch 感知实例变化。
- 配置中心：集中存储全局配置，Watch 实现动态更新，无需重启服务。
- 分布式锁：Lease + 原子操作实现，客户端宕机锁自动过期，无死锁。
- 集群协调：Kubernetes 存储 Pod、Node 等元数据，Leader 选举、任务调度协调。
4. 核心工作原理（Raft 算法）
Raft 将一致性分解为 选主、日志复制、安全性 三个子问题：
- 角色与选主 ：
- 角色：Leader（处理所有读写）、Follower（同步日志、参与选举）、Candidate（选举中）。
- 流程：Follower 超时未收 Leader 心跳 → 转为 Candidate 自增 Term 发起投票 → 获多数票成为 Leader → 发心跳维持权威。
- 日志复制 ：
- 客户端写请求发往 Leader → Leader 追加日志 → 并行复制到 Follower → 获多数 ACK 后提交（commit）→ 执行并返回结果。
- 日志含 Term（任期号）和 Index（索引），保证数据顺序一致。
5. 与 ZooKeeper 对比
表格
| 对比项 | etcd | ZooKeeper |
|---|---|---|
| 一致性算法 | Raft（易理解） | Paxos（复杂） |
| 开发语言 | Go（轻量无依赖） | Java（依赖 JVM） |
| 数据模型 | 扁平键值，前缀查询 | 层级 ZNode |
| 核心机制 | Lease 租约（灵活过期） | 临时节点（TTL 固定） |
| 典型场景 | 云原生（K8s）、高并发写 | 传统分布式（Hadoop、Kafka） |
| 选型建议 | 云原生、微服务、需要灵活过期 | 传统大数据生态、强顺序需求 |
6. 实践要点
- 集群部署：奇数节点（3/5/7），建议至少 3 节点，保证容错。
- 租约设计：TTL 合理设置（如 3-10 秒），避免频繁续租或过期误删。
- Watch 优化：监听前缀而非单个键，减少资源消耗；处理重连，避免丢事件。
- 性能优化：读多写少场景可缓存数据；避免大键（单键≤1.5MB）。
三、CAP 与 etcd 的关联
etcd 是 CP 系统 的典型代表：
- 满足 分区容忍性（P）：网络分区时仍能通过 Raft 选主维持服务。
- 优先保证 一致性（C）：所有节点数据一致，写后读必获最新值。
- 牺牲部分可用性：网络分区或节点故障时，可能短暂不可用，但数据不丢失、不一致。
四、面试高频考点
- CAP 定理三要素定义：准确解释 C/A/P 的含义及不可兼得的原因。
- etcd 为什么是 CP 系统：结合 Raft 算法说明一致性优先、可用性让步的逻辑。
- etcd 租约与 Watch 机制：解释租约过期自动清理、Watch 实时通知的作用。
- BASE 与 CAP 的关系：说明 BASE 是 CAP 的落地实践，如何平衡一致性与可用性。
- etcd 与 ZooKeeper 选型：根据业务场景（云原生 / 传统分布式）给出选择理由。