目录一、分布式架构核心概念
1. 分布式系统的基本特征
| 特征 | 含义 | 考试重点 |
|---|---|---|
| 分布性 | 节点物理分散，通过通信网络连接 | 与集中式系统的本质区别 |
| 自治性 | 各节点独立运行，具备处理能力 | CAP理论的前提条件 |
| 并发性 | 多节点并行处理请求 | 数据一致性问题根源 |
| 全局性 | 对外呈现统一整体 | 透明性设计目标 |
2. CAP理论（必考⭐）
定理内容：分布式系统最多同时满足以下两项：
┌─────────────────────────────────────┐
│ Consistency (一致性) │
│ 所有节点在同一时刻看到相同数据 │
├─────────────────────────────────────┤
│ Availability (可用性) │
│ 每个请求都能在有限时间内获得响应 │
├─────────────────────────────────────┤
│ Partition Tolerance (分区容错性) │
│ 网络分区时系统仍能继续运行 │
└─────────────────────────────────────┘典型组合：
- CP（一致性+分区容错）：ZooKeeper、HBase、etcd
- AP（可用性+分区容错）：Cassandra、DynamoDB、Eureka
- CA（一致性+可用性）：传统单机数据库（非分布式）
🔑 考点 ：P分区容错在分布式系统中必须满足，实际选择往往在C和A之间权衡。
二、分布式架构模式
1. 经典架构模式对比
| 模式 | 结构特点 | 适用场景 | 典型技术 |
|---|---|---|---|
| 分层架构 | 表现层→业务层→数据层 | 传统企业应用 | MVC、三层架构 |
| 微服务架构 | 服务拆分，独立部署 | 大型互联网应用 | Spring Cloud、Dubbo |
| SOA架构 | 企业服务总线(ESB) | 企业系统集成 | WebService、ESB |
| 事件驱动架构 | 异步消息传递 | 高并发、解耦场景 | Kafka、RabbitMQ |
| CQRS模式 | 读写分离 | 读多写少场景 | Event Sourcing |
2. 微服务核心组件
┌─────────────────────────────────────────┐
│ 服务注册与发现 (Eureka/Nacos) │
├─────────────────────────────────────────┤
│ 配置中心 (Config/Apollo) │
├─────────────────────────────────────────┤
│ 负载均衡 (Ribbon) │ 服务网关 (Gateway) │
├─────────────────────────────────────────┤
│ 熔断降级 (Hystrix/Sentinel) │
├─────────────────────────────────────────┤
│ 链路追踪 (Sleuth/SkyWalking) │
└─────────────────────────────────────────┘三、分布式一致性协议
1. 一致性级别
| 级别 | 定义 | 实现复杂度 |
|---|---|---|
| 强一致性 | 任何时刻读取都是最新值 | 高（2PC/Paxos） |
| 弱一致性 | 不保证立即读到最新值 | 低 |
| 最终一致性 | 无新更新后，最终达到一致 | 中（BASE理论） |
2. 核心协议详解
2PC（两阶段提交）
阶段一（投票）：
协调者 → 询问所有参与者是否可以提交
参与者 → 执行本地事务，锁定资源，返回Yes/No
阶段二（执行）：
全部Yes → 协调者发送Commit，参与者提交
任一No → 协调者发送Rollback，参与者回滚缺点：同步阻塞、单点故障、脑裂问题
3PC（三阶段提交）
增加CanCommit预询问阶段，减少阻塞时间，引入超时机制。
Paxos算法
角色：
• Proposer（提议者）：提出提案
• Acceptor（接受者）：投票表决
• Learner（学习者）：获取结果
流程：
1. Prepare阶段：Proposer获取提案编号n
2. Promise阶段：Acceptor承诺不接受<n的提案
3. Accept阶段：Proposer发送(n, value)
4. Accepted阶段：Acceptor接受多数派value🔑 考点 ：Paxos是多数派协议，不要求全部节点同意。
Raft算法（简化版Paxos）
| 角色 | 职责 |
|---|---|
| Leader | 处理所有客户端请求，日志复制 |
| Follower | 被动接收日志，响应Leader |
| Candidate | 选举期间临时角色 |
核心机制：领导者选举 + 日志复制 + 安全性
四、分布式事务解决方案
方案对比
| 方案 | 原理 | 一致性 | 性能 | 适用场景 |
|---|---|---|---|---|
| 2PC/3PC | 协调者统一提交/回滚 | 强一致 | 差 | 传统金融系统 |
| TCC | Try-Confirm-Cancel | 最终一致 | 好 | 电商、支付 |
| Saga | 长事务拆分+补偿 | 最终一致 | 好 | 长流程业务 |
| 本地消息表 | 异步确保 | 最终一致 | 好 | 跨系统通知 |
| Seata AT | 自动生成反向SQL | 最终一致 | 较好 | 微服务架构 |
TCC详解
Try阶段：预留资源（冻结库存、预扣金额）
↓ 全部成功
Confirm阶段：确认执行（真正扣减）
↓ 任一失败
Cancel阶段：释放预留资源（回滚）五、典型考点例题
例题1：CAP理论应用（单选）
题目：某电商系统在大促期间，为保证用户下单体验，允许短暂的数据不一致，但要求系统始终可用。该设计遵循了CAP理论的哪种组合？
A. CA
B. CP
C. AP
D. PACELC
答案：C
解析：
- "始终可用" → 满足A（可用性）
- "短暂数据不一致" → 牺牲C（一致性）
- 分布式系统必须满足P（分区容错）
- 因此选择AP架构，如使用Eureka做服务发现，Cassandra做数据存储。
例题2：一致性协议（多选）
题目：关于Paxos和Raft算法，以下说法正确的是？
A. Paxos要求所有Acceptor都接受提案才能生效
B. Raft通过心跳机制检测Leader故障
C. Paxos中Proposer可以兼任Acceptor
D. Raft的日志必须按顺序连续提交
答案：B、C、D
解析：
- A错误 ：Paxos是多数派协议，多数Acceptor接受即可（通常>50%）。
- B正确：Raft使用心跳和随机超时触发选举。
- C正确：节点可同时担任多个角色。
- D正确：Raft要求日志连续性，这是与Paxos的主要区别。
例题3：分布式事务（案例分析）
题目：某银行转账系统需要实现跨行转账功能，要求数据强一致性。请分析：
- 应选择哪种分布式事务方案？
- 画出该方案的执行流程图。
参考答案：
1. 方案选择 ：2PC（两阶段提交） 或 TCC
- 银行场景要求强一致性，首选2PC
- 若追求性能可接受最终一致，可选TCC
2. 2PC流程图：
协调者（事务管理器）
│
┌─────────┼─────────┐
↓ ↓ ↓
工行节点 银联节点 农行节点
│ │ │
└────┬────┘ │
↓ │
阶段一：Vote │
（锁定账户余额） │
│ │
┌────┴────┐ │
↓ ↓ ↓ │
Yes Yes Yes │
│ │ │
└────┬────┘ │
↓ │
阶段二：Commit │
（实际扣款/入账） │
│ │
┌────┴────┐ │
↓ ↓ ↓ │
成功 成功 成功 ←── 全部成功例题4：微服务设计（综合题）
题目：某大型电商平台采用微服务架构，包含订单、库存、支付、物流等服务。请回答：
- 服务间调用失败时，应采取什么措施保证系统稳定性？
- 如何设计服务间的数据一致性？
参考答案：
1. 稳定性措施：
| 措施 | 实现方式 | 作用 |
|---|---|---|
| 熔断 | Hystrix/Sentinel | 失败率过高时快速失败，防止雪崩 |
| 降级 | 返回默认值/缓存数据 | 保证核心功能可用 |
| 限流 | 令牌桶/漏桶算法 | 控制并发量，保护系统 |
| 超时 | 设置合理的RPC超时 | 避免长时间阻塞 |
| 重试 | 指数退避策略 | 网络抖动时自动恢复 |
2. 数据一致性设计：
场景：下单扣减库存
方案：Saga事务（编排式）
订单服务 ──→ 创建订单 ──┐
↓
库存服务 ←── 扣减库存 ←──┘
│
↓ 扣减成功
支付服务 ←── 发起支付
│
↓ 支付成功
物流服务 ←── 创建物流单
补偿流程：
若支付失败 → 库存服务：恢复库存
→ 订单服务：取消订单六、高频考点速记
| 考点 | 关键记忆点 |
|---|---|
| BASE理论 | Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致） |
| 幂等性 | 同一操作多次执行结果相同，通过唯一键/Token实现 |
| 脑裂 | 网络分区导致多个Leader，通过Quorum机制避免 |
| Gossip协议 | 去中心化，病毒式传播，用于Cassandra、Redis Cluster |
| 一致性Hash | 解决节点增减时的数据迁移问题，引入虚拟节点 |
附录：常用工具与框架
服务治理
- 注册中心：Nacos、Consul、ZooKeeper、Eureka
- 配置中心：Apollo、Nacos、Spring Cloud Config
- 网关：Spring Cloud Gateway、Kong、Nginx
消息队列
- Kafka：高吞吐，日志收集
- RocketMQ：金融级可靠，事务消息
- RabbitMQ：灵活路由，企业应用
缓存与存储
- Redis：分布式缓存、分布式锁
- Etcd：配置存储、服务发现
- Consul：服务网格、健康检查