从零开始学习JavaWeb-20
一、分布式一致性的理论基础
1. CAP 定理与一致性模型
CAP 定理核心：
特性
描述
业务场景
一致性 (C)
所有节点数据实时同步
金融交易（支付状态强同步）
可用性 (A)
每次请求均获响应（可能非最新数据）
电商商品浏览（允许短暂延迟）
分区容错性 (P)
网络分裂时系统继续运作
跨机房部署（必须保障）
实践启示：
CP 系统（如 ZooKeeper）：牺牲可用性保障强一致性（如银行转账）。
AP 系统（如 Cassandra）：牺牲一致性保障高可用（如实时推荐系统）。
一致性模型分类：
强一致性：写入后立即可读（线性一致性），通过 Paxos/Raft 实现（如 Etcd）。
最终一致性：无新写入后终态一致（如 DNS 系统），基于 Gossip 协议。
二、主流分布式一致性算法
1. Paxos 协议：理论基石
角色与两阶段流程：
sequenceDiagramProposer->>Acceptor: Prepare(n)Acceptor-->>Proposer: Promise(ignore <n)Proposer->>Acceptor: Accept(n, v)Acceptor-->>Proposer: Accepted(n, v)核心机制：
提案编号全局唯一：避免冲突（时间戳 + 节点 ID）。
多数派原则（Quorum）：需半数以上节点同意（故障容忍公式：
f < N/2）。工程缺陷：实现复杂，多轮通信开销大（Google Chubby 团队曾称“理解需 6 个月”）。
2. Raft 协议：工业级首选
角色状态机：
graph LRFollower -->|选举超时| CandidateCandidate -->|获多数票| LeaderLeader -->|故障| Follower核心流程：
领导者选举：节点超时未收心跳 → 成为 Candidate → 获多数票成为 Leader。
日志复制：
Leader 接收写请求生成 Log Entry。
并行发送 AppendEntries RPC 至 Followers。
多数节点持久化后提交日志。
优势：逻辑清晰，易于实现（etcd、Consul 采用）。
3. ZAB 协议：ZooKeeper 的引擎
与 Raft 关键差异：
特性 | Raft | ZAB |
|---|---|---|
任期命名 | Term | Epoch |
心跳方向 | Leader → Follower | Follower → Leader |
写操作流程 | 先广播后持久化 | 先本地持久化后广播 |
崩溃恢复模式：选举最高 zxid 节点 → 数据同步 → 广播新 Leader。
三、分布式锁的实现方案
1. 三大实现方式对比
方案 | 核心原理 | 适用场景 | 性能 |
|---|---|---|---|
数据库锁 | 唯一索引约束（ | 低并发简单场景 | ⭐ |
Redis 锁 |
| 高并发，允许偶尔失效 | ⭐⭐⭐⭐⭐ |
ZooKeeper 锁 | 临时顺序节点 + Watcher 监听 | 强一致性需求（如金融） | ⭐⭐⭐ |
Redis 锁避坑：
锁续期：Redisson 看门狗机制自动续期（默认 30 秒检测）。
误释放：Lua 脚本校验 UUID 再释放（
if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1])）。
四、分布式事务解决方案
1. Seata AT 模式
两阶段流程：
graph TBTM[事务管理器] --> TC[事务协调器]TC --> RM1[资源管理器]TC --> RM2[资源管理器]RM1 --> DB1[生成 undo_log]RM2 --> DB2[生成 undo_log]核心机制：
全局锁：
SELECT FOR UPDATE防止其他事务修改数据。回滚日志：记录数据修改前后的快照（SQL 反向补偿）。
2. TCC 模式
三阶段操作：
Try：预留资源（如冻结库存）。
Confirm：实际提交（扣减库存）。
Cancel：失败回滚（解冻库存），需业务幂等设计。
适用场景：高一致性要求（如机票超卖后的退款补偿）。
五、工业级实战案例
1. 电商订单支付系统
高并发设计：
graph TB用户 -->|下单| 订单服务订单服务 -->|发送 MQ| 库存服务库存服务 --> Redis[预减库存]库存服务 --> DB[持久化库存]订单服务 -->|TCC| 支付服务关键保障：
库存预扣：Redis 原子操作防超卖（
DECR stock_count）。最终一致性：支付成功消息异步更新订单状态（MQ 重试机制）。
2. 配置中心高可用（Nacos）
架构要点：
数据分片：配置按 Group 分片存储。
多级缓存：客户端内存缓存 + 服务端 Redis 缓存。
长轮询：配置变更实时推送（30 秒超时）。
六、算法选型与未来趋势
1. 一致性协议选型指南
特性 | Paxos | Raft | ZAB |
|---|---|---|---|
理解难度 | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ |
性能 | 高（无 Leader 瓶颈） | 中高（依赖 Leader） | 高 |
适用场景 | 理论验证 | 通用系统（etcd） | 协调服务（ZooKeeper） |
选型建议：
快速落地 → Raft（etcd/Consul）。
强协调服务 → ZAB（ZooKeeper）。
2. 前沿趋势
性能突破：RDMA 网络加速共识通信（延迟降低 80%）。
安全增强：抗量子计算签名算法集成（如 Dilithium）。
无主协议兴起：EPaxos 优化跨地域部署。
总结：分布式系统设计原则
故障是常态：默认节点会宕机、网络会分区（冗余副本 + 自动故障转移）。
异步解耦：消息队列（Kafka）解耦耗时操作（如日志记录）。
幂等性：所有操作支持重试（唯一请求 ID 防重复）。
监控先行：分布式追踪（SkyWalking） + 日志聚合（ELK）。
“分布式系统的本质是在不确定性中寻求确定性”
动手实践：
基于 Redisson 实现秒杀库存锁（对比 Redis 与 ZooKeeper 性能）。
模拟网络分区（
iptables断网），观察 ZooKeeper 选举行为。压测 Seata AT 模式与 TCC 模式的性能差异。