大厂后端 P6+/高级岗位的分水岭——分布式题答得深不深,直接决定能不能过技术终面。 本模块定位为"分布式理论 + 通用基础设施"层——覆盖任何分布式系统(DB 集群 / MQ / 缓存 / 微服务)都会遇到的问题。
① 解决三个核心问题:
- 怎么保证数据一致(CAP/BASE → 一致性算法 → 分布式事务)
- 怎么唯一标识 + 协调多节点(分布式 ID → 分布式锁 → 一致性哈希)
- 怎么避免重复执行(幂等:6 种方案) ② 跟其它模块的关系(理论 + 实现 在本模块;微服务专属工程在 Microservice):
- 理论 + 通用基础设施 + Seata 实现 → 本模块(CAP / Raft / 事务 / 锁 / ID / 哈希 / 幂等 / Seata)
- 微服务专属工程 + Spring Cloud 实现 → Microservice 模块(注册发现 / 治理 / 限流 / 追踪 / Nacos / Sentinel / Feign / Gateway)
- Spring Framework + Boot 单进程基础 → Spring 模块(IoC / AOP / 事务 / 自动装配)
| 文档 | 一句话定位 |
|---|---|
| CAP 与 BASE 理论 | CAP 三选二的工程含义、为什么 P 必选、AP/CP 实例对照 |
| 一致性算法 | Paxos / Raft / ZAB / Gossip 横向对比、各组件用什么算法 |
| 文档 | 一句话定位 |
|---|---|
| 分布式事务 | 2PC/3PC/TCC/本地消息表/事务消息/Saga/Seata AT 全景 |
| Seata 分布式事务 | AT 模式 undo_log 自动补偿 / TCC / Saga / XA 模式选型(工业实现) |
| 幂等 | 6 种幂等方案 + 业务唯一键/Token/状态机/分布式锁 |
| 文档 | 一句话定位 |
|---|---|
| 分布式锁 | Redis vs ZooKeeper vs etcd 三方对比、Redlock 之争 |
| 分布式 ID | UUID/雪花/号段/Leaf/Tinyid,时钟回拨问题 |
| 一致性哈希 | 哈希环、虚拟节点、Memcached/Dubbo/CDN 应用 |
注意:服务注册与发现 / 服务治理 / 限流算法 / 链路追踪是微服务专属工程模式——见 Microservice 模块。它们不是"任何分布式系统"都需要的(DB 集群 / MQ 自身都不需要),所以单独成模块。
| 高频题 | 跳转 |
|---|---|
| CAP 是什么?为什么 P 必选? | CAP 与 BASE |
| BASE 和 ACID 的区别? | CAP 与 BASE |
| 哪些组件是 CP,哪些是 AP? | CAP 与 BASE |
| Paxos 和 Raft 的区别? | 一致性算法 |
| Raft 怎么 Leader 选举? | 一致性算法 |
| Raft 网络分区怎么办? | 一致性算法 |
| ZAB 跟 Raft 的差异? | 一致性算法 |
| 2PC 的"数据不一致窗口"在哪? | 分布式事务 |
| TCC 怎么解决空回滚和悬挂? | 分布式事务 |
| 本地消息表和事务消息怎么选? | 分布式事务 |
| Saga 适合什么场景? | 分布式事务 |
| Seata AT 的全局锁是怎么回事? | 分布式事务 / Seata 分布式事务 |
| Seata AT/TCC/Saga/XA 怎么选? | Seata 分布式事务 |
| TCC 三大问题(空回滚/悬挂/幂等)? | Seata 分布式事务 |
| 接口怎么做幂等? | 幂等 |
| Token 幂等的原子性怎么保证? | 幂等 |
| MQ 消费幂等怎么做? | 幂等 |
| 分布式锁 Redis 还是 ZK? | 分布式锁 |
| Redlock 为什么有争议? | 分布式锁 |
| 分布式锁怎么防止误删? | 分布式锁 |
| Redisson 看门狗怎么工作? | 分布式锁 |
| 雪花算法时钟回拨怎么处理? | 分布式 ID |
| 号段模式怎么避免性能毛刺? | 分布式 ID |
| 怎么设计一个全局 ID 生成器? | 分布式 ID |
| 一致性哈希为什么要虚拟节点? | 一致性哈希 |
| Redis Cluster 为什么不用一致性哈希? | 一致性哈希 |
[CAP 与 BASE 理论]
↓ 选 AP/CP
[一致性算法]
Paxos/Raft/ZAB/Gossip
↓ 落地为协议
┌───────────────┼───────────────┐
│ │ │
[分布式事务] [分布式锁] [分布式 ID]
2PC/TCC/Saga Redis/ZK/etcd 雪花/号段/Leaf
↑ ↑
│ │
[幂等] ←───────────┘ ← 重试场景必备
↑
[一致性哈希] ── 数据分片基石
核心传导:CAP → 一致性算法 → 落到事务/锁/ID 上;幂等是所有分布式调用的兜底。
分布式不是孤立的——理论在本模块,实现散在四处:
| 主题 | Distributed(理论) | 实现位置 |
|---|---|---|
| 共识协议 | 一致性算法 | Redis/集群部署(Gossip) Microservice/Nacos(Distro/Raft) |
| 分布式锁 | 分布式锁(横向对比) | Redis/分布式锁(Redisson 看门狗细节) |
| 分布式事务 | 分布式事务(理论 + 选型) | Seata 分布式事务(AT/TCC 工业实现) MQ/事务消息(RocketMQ half message) |
| 缓存一致性 | 分布式事务 | Redis/双写一致性 |
| 消费幂等 | 幂等 | MQ/重复消费与幂等 |
| 一致性哈希 | 一致性哈希 | Redis/集群部署(16384 slot 对比) |
| 微服务工程 | — | Microservice 模块(注册发现 / 治理 / 限流 / 追踪) |
1. CAP 与 BASE 理论 ← 必须先建立的世界观
2. 一致性算法 ← Raft 是后面所有 CP 系统的基石
3. 分布式事务(先看方案全景) ← 业务最常碰到
4. 幂等 ← 跟事务配套,必学
5. 分布式锁 ← 高频面试题
6. 分布式 ID ← 架构基础设施
7. 一致性哈希 ← 数据分片
↓ 进入微服务工程层
8. Microservice/服务注册与发现
9. Microservice/服务治理 + 限流算法
10. Microservice/链路追踪
每篇都已配 答题模板(30/60 秒话术)——直接复述就是 senior 级回答:
| 方案 | 一致性 | 性能 | 复杂度 | 业务侵入 | 代表场景 |
|---|---|---|---|---|---|
| 2PC / XA | 强一致 | 差(×3-5) | 中 | 低 | 银行核心、传统行业 |
| TCC | 强一致 | 中 | 高 | 大 | 金融支付、转账 |
| 本地消息表 | 最终一致 | 高 | 低 | 中 | 互联网主流 |
| 事务消息 | 最终一致 | 高 | 低 | 中 | RocketMQ 体系 |
| Saga | 最终一致 | 高 | 中 | 中 | 长流程(订单/旅游) |
| Seata AT | 最终一致 | 中 | 低 | 几乎无 | 中小团队微服务 |
| 最大努力通知 | 最终一致 | 高 | 低 | 低 | 第三方回调、短信 |
| 维度 | Paxos | Raft | ZAB | Gossip |
|---|---|---|---|---|
| 一致性 | 强一致 | 强一致 | 强一致 | 最终一致 |
| Leader | Multi-Paxos 才有 | 必有 | 必有 | 无 |
| 可理解性 | 极难 | 易 | 中 | 易 |
| 可扩展 | 中 | 中 | 中 | 千节点 |
| 典型实现 | Chubby、Spanner | etcd、TiKV | ZooKeeper | Redis Cluster、Cassandra |
| 维度 | Redis | ZooKeeper | etcd |
|---|---|---|---|
| 一致性 | AP(可能丢锁) | CP(强一致) | CP(Raft) |
| 性能 | 最高(10w+ QPS) | 中(1w QPS) | 中(2w QPS) |
| 实现复杂度 | 低(Redisson) | 中(Curator) | 中 |
| 锁失效检测 | TTL + 看门狗 | 临时节点 | Lease + KeepAlive |
| 适用场景 | 高并发、容错性强 | 强一致、低并发 | K8s 生态 |
| 方案 | 趋势递增 | 性能 | 依赖 | 缺点 |
|---|---|---|---|---|
| UUID | ❌ | 极高 | 无 | 36 字符、无序、索引差 |
| 数据库自增 | ✅ | 低 | DB | 单点、瓶颈 |
| Redis INCR | ✅ | 高 | Redis | 持久化要权衡 |
| 雪花算法 | ✅ | 极高 | 无 | 时钟回拨 |
| 号段模式 | ✅ | 高 | DB | 重启浪费 |
| Leaf-Segment | ✅ | 高 | DB | 美团方案 |
| Leaf-Snowflake | ✅ | 极高 | ZK | 解决时钟回拨 |
- TCC 空回滚:Try 还没到 Cancel 先到 → 必须在 Cancel 中识别"事务无 Try 记录"才能拒绝。→ 分布式事务
- Redis 锁误删:A 锁过期 B 拿到锁,A 删了 B 的锁 → value 加 UUID + Lua 删锁。→ 分布式锁
- Redlock 时钟漂移:节点时钟跳变导致同时多人持锁 → Martin Kleppmann 反对的核心。→ 分布式锁
- 雪花算法时钟回拨:NTP 校时回拨 → ID 重复、严重事故 → Leaf-Snowflake 用 ZK 持久化时间戳。→ 分布式 ID
- 号段重启浪费:进程重启丢掉一段号段 → 业务忍受不连续 + 监控水位。→ 分布式 ID
- 本地消息表扫表慢:上千万消息后扫表卡死 → 分库分表 + 状态字段索引 + 时间分区。→ 分布式事务
- 事务消息回查打挂 DB:回查接口非幂等,多次回查触发业务 SQL → 改为只读 + 幂等。→ 分布式事务
- Seata AT 高并发热点:秒杀场景全局锁阻塞 → 改 TCC + Redis 预扣。→ 分布式事务
- 幂等键设计错误:用业务字段拼凑而非全局唯一 → 重复执行。→ 幂等
- Raft 选举超时设太短:网络抖动频繁误判 Leader 死亡 → 集群震荡。→ 一致性算法
按出现频率列出(每条主线对应至少一篇深度文档):
- CAP:定义 → P 为什么必选 → AP/CP 例子 → BASE → 跟 ACID 的关系
- 一致性算法:Paxos 两阶段 → Raft 三件套(选举/复制/安全)→ 网络分区脑裂处理
- 分布式事务:CAP → BASE → 2PC 的阻塞 → TCC 的三个坑 → 本地消息表 vs 事务消息 → Saga 适用场景 → Seata AT 全局锁
- 分布式锁:SETNX → 误删 → UUID + Lua → Redisson 看门狗 → Redlock → Redlock 争议 → ZK 临时节点 → 选型
- 幂等:场景 → 唯一键 / 状态机 / Token / 分布式锁 → Token 原子性(Redis Lua)→ 跟事务的关系
- 分布式 ID:UUID 缺点 → 雪花算法 → 时钟回拨 → 号段模式 → Leaf 双 buffer → 选型
- 一致性哈希:动机 → 哈希环 → 虚拟节点(150 个)→ 应用场景 → 跟 Redis Cluster slot 对比
- Microservice 模块 — 微服务工程模式(注册发现 / 治理 / 限流 / 追踪)
- Spring 模块 — Spring Framework + Boot 单进程基础(IoC/AOP/事务/自动装配)
- Redis 模块 — 缓存中间件,分布式锁/消息队列实现层
- MQ 模块 — 消息中间件,事务消息/可靠投递
- MySQL 模块 — 单库 ACID + 分库分表
- Project 模块 — 高并发实战、订单中心、性能优化