分布式核心知识

一、分布式基础概念

1. 什么是分布式

把一个单体系统拆分成多个独立服务，部署在不同服务器，通过网络协作完成业务，分担压力、提升并发与可用性。

2. 单体 vs 分布式

• 单体：代码集中、部署简单，高并发/大流量易瓶颈，牵一发而动全身。
• 分布式：服务解耦、可弹性扩容、团队并行开发，引入网络、数据一致性、调用复杂度等新问题。

3. 三大理论（面试必背）

CAP 定理

分布式系统无法同时满足一致性©、可用性(A)、分区容错性§，分区容错必选，只能在 C 和 A 之间取舍：

• CP：保证一致性，牺牲可用性（如 ZooKeeper）
• AP：保证可用性，牺牲强一致性（如 Eureka、大部分业务系统）

BASE 理论

对 CAP 的落地实践，互联网主流方案：

• 基本可用：故障时保证核心功能可用，允许部分降级
• 软状态：数据允许短暂不一致
• 最终一致性：数据最终会达成一致，不要求实时一致

一致性算法

• Paxos：经典强一致算法，实现复杂
• Raft：简化版 Paxos，易实现，主流（Nacos、Etcd、RocketMQ 均使用）

二、分布式四大核心问题 & 解决方案

1. 分布式会话（Session 共享）

问题：请求分发到不同服务/节点，原生 Session 不互通。
方案：

1. 统一会话存储：Redis 集中存放 Session
2. 前端 Token：无状态登录，JWT 主流方案
3. 粘性会话（不推荐，负载不均）

2. 分布式 ID

问题：单机自增 ID 无法在多节点全局唯一。
常用方案：

1. UUID：简单，无序、过长、索引差
2. 数据库自增：简单，单点瓶颈
3. 雪花算法(SnowFlake)：主流，64位二进制，有序、高性能
4. Redis 自增：适合中小型系统
5. 百度 UID、美团 Leaf：开源 ID 生成器

3. 分布式锁

问题：多服务/多节点竞争同一资源，保证互斥访问。

主流实现

1. 基于 Redis
   • 核心：SET key value NX EX 过期时间
   • 问题：死锁、锁续期、锁误删、主从同步延迟
   • 成熟框架：Redisson（看门狗续期、可重入、公平锁）
2. 基于 ZooKeeper
   • 临时有序节点 + 监听，性能略低于 Redis，一致性更强
3. 基于数据库
   • 悲观锁/乐观锁，性能差，仅低并发场景使用

4. 分布式事务（最难考点）

问题：跨多个服务/库，保证事务要么全部成功、要么全部回滚。

四大经典方案

1. 2PC（两阶段提交）
   准备阶段 → 提交/回滚；强一致，性能差，不适合高并发。
2. TCC（补偿事务）
   Try(检查/预留) → Confirm(确认) → Cancel(回滚)；代码侵入高，性能较好。
3. 本地消息表（异步确保）
   本地事务 + 消息表 + 轮询补发；实现简单，业界常用。
4. SAGA 模式
   长事务拆分，每个子事务配反向回滚操作。

主流框架

Seata：阿里开源，一站式分布式事务框架，支持 AT、TCC、SAGA 等模式，项目首选。

三、分布式核心组件（企业必用）

1. 注册中心（服务发现）

作用：服务注册、健康检测、地址拉取，解耦服务硬编码。

• Nacos：国内主流，集注册中心+配置中心+动态DNS，兼容 AP/CP
• Eureka：SpringCloud 原生，AP 架构，已停止更新
• ZooKeeper：CP 架构，强一致，适合配置/选举，不建议纯服务注册

2. 配置中心

作用：统一管理配置、动态刷新，无需重启服务。

• Nacos / Apollo / Spring Cloud Config

3. 网关 Gateway

作用：请求入口，统一路由、限流、熔断、鉴权、日志、灰度发布。
主流：Spring Cloud Gateway（替代旧版 Zuul）

4. 消息队列 MQ（异步解耦、削峰填谷）

核心场景：异步处理、流量削峰、服务解耦、数据同步。
主流中间件：

• RocketMQ：阿里出品，功能全，事务消息优秀，国内电商首选
• Kafka：高吞吐，大数据、日志收集首选
• RabbitMQ：可靠性高，社区成熟

5. 熔断 & 限流 & 降级（高可用三板斧）

问题：服务雪崩（下游故障层层向上传导）。

• 熔断：下游异常多，直接切断调用，避免雪崩（Sentinel、Resilience4j）
• 限流：限制请求量，保护服务不被打垮（令牌桶、漏桶算法）
• 降级：非核心功能暂时关闭，保证核心业务可用

主流组件：Sentinel（阿里，轻量、功能全，国内首选）、Hystrix（停更）

6. 远程调用（RPC）

作用：跨服务方法调用，像调用本地方法一样简单。

• OpenFeign：SpringCloud 原生，HTTP 协议，易用
• Dubbo：阿里开源，TCP 协议，高性能 RPC 框架，微服务经典
• gRPC：谷歌，跨语言，适合跨语言调用

四、分布式高可用 & 高并发设计

1. 集群部署：服务多节点，单点故障不影响整体
2. 负载均衡
   • 客户端负载：Feign、Dubbo 内置（轮询、随机、加权轮询、一致性哈希）
   • 服务端负载：Nginx
3. 缓存体系
   • 本地缓存：Caffeine、Guava
   • 分布式缓存：Redis（缓存穿透、击穿、雪崩三大问题及解决方案）
4. 读写分离 & 分库分表
   • 读写分离：主库写、从库读，缓解单库压力
   • 分库分表：水平分表、垂直分表，解决单表数据量过大问题
   • 中间件：Sharding-JDBC、MyCat

五、高频面试题（精简答案）

1. CAP 和 BASE 怎么理解？
   CAP 三选二，分区容错必然存在；BASE 是最终一致性，互联网分布式系统主流选型。
2. Redis 分布式锁存在哪些问题？怎么解决？
   死锁（加过期时间）、锁误删（唯一标识）、续期（Redisson 看门狗）、主从延迟（Redlock）。
3. 分布式事务有哪些方案？项目中用哪种？
   2PC、TCC、本地消息表、SAGA；项目常用 Seata AT 模式。
4. 为什么要用消息队列？
   解耦、削峰、异步、流量控制。
5. 服务雪崩怎么防护？
   熔断、限流、降级、超时控制、重试机制。
6. Nacos 和 ZooKeeper 区别？
   Nacos 偏向 AP，可用性高，适合微服务注册；ZK 偏向 CP，一致性强，适合配置、选举。

六、学习路线（循序渐进）

1. 理解 CAP/BASE 理论
2. 分布式 ID、分布式锁
3. 注册中心 + 配置中心（Nacos）
4. RPC 远程调用（Dubbo/Feign）
5. 网关 Gateway
6. 熔断限流降级（Sentinel）
7. 消息队列 MQ
8. 分布式事务（Seata）
9. 缓存、分库分表、读写分离