CAP 理论与一致性模型：从理论到工程取舍

// ZAB 两种模式
1. 崩溃恢复模式（Leader Election）
   - Leader 挂掉后，Follower 选举新 Leader
   - 必须选到包含最新数据的节点（zxid 最大的）
   - 新 Leader 同步数据给 Follower，确保多数派数据一致

2. 消息广播模式（Atomic Broadcast）
   - 所有写请求转发到 Leader
   - Leader 生成事务提案 → 发给 Follower
   - Follower 写入本地日志 → 返回 ACK
   - 收到多数派 ACK → Leader 发送 COMMIT
   - // 本质是一个简化版的 2PC

// 写一致性保证
顺序一致性：所有事务按 zxid 全局有序
原子性：事务要么全集群成功，要么全失败

// 三种角色
Leader  — 处理所有读写（可配置读走 Follower）
Follower — 被动接收日志，超时未收到心跳则发起选举
Candidate — 发起选举，获得多数票后成为 Leader

// 日志复制流程
1. Client 向 Leader 发送写请求
2. Leader 将日志条目追加到本地日志
3. Leader 并行发送 AppendEntries RPC 给所有 Follower
4. 收到多数派 ACK → Leader 将日志标记为 committed
5. Leader 将 committed 日志应用到状态机，返回结果给 Client

// 关键约束
Election Safety：一个任期最多一个 Leader
Log Matching：两个日志在相同索引和任期号处，内容相同

// Eureka 集群中每个节点都是对等的
// 节点间通过 P2P 复制，没有 Leader

服务注册：
  → 注册到任意一个 Eureka 节点
  → 该节点异步复制到所有其他节点
  → 复制失败？不管，继续接受新请求

服务发现：
  → 从任意节点查询
  → 可能返回的数据比其他节点"旧一点"
  → 但对于服务发现来说，几秒的延迟完全可以接受

// 关键设计：自我保护模式
Self-Preservation：
  当 15 分钟内超过 85% 的心跳没有收到时
  → 进入自我保护模式
  → 不剔除任何服务实例（宁可保留过期数据）
  → 宁可返回可能不正确的数据，也不让服务列表为空

// 写操作的一致性级别
ONE     — 写到一个副本就返回（延迟最低，一致性最弱）
QUORUM  — 写到多数派副本才返回（N/2+1 个节点）
ALL     — 写到所有副本才返回（一致性最强，延迟最高）

// 读操作的一致性级别
ONE     — 从一个副本读取（最快，可能读到旧数据）
QUORUM  — 从多数派读取并比较（强一致性保证）
LOCAL_QUORUM — 只在本地数据中心的多数派中读取

// 强一致性的条件：R + W > N
// R = 读节点数，W = 写节点数，N = 副本总数
// 例：N=3, R=2, W=2 → 读写必有交集 → 读到最新数据

// 场景：用户下单扣减库存

基本可用：
  大促时库存扣减压力大 → 允许先扣减 Redis 缓存库存
  异步同步到数据库 → 用户感知到的是"下单成功"

软状态：
  购物车数量、商品浏览量 → 允许短暂不准确
  推荐列表 → 允许几秒前的缓存数据

最终一致：
  订单创建 → 发送 MQ 消息 → 库存服务异步扣减
  如果扣减失败 → 定时对账任务补偿
  // 保证"订单状态"和"库存数量"最终一致

// 核心交易层 — 偏 CP
支付、转账、库存扣减：
  必须保证数据一致性 → 宁可暂时不可用
  使用 TCC 或 Saga 分布式事务保证最终一致
  // BASE 的应用：允许异步扣减，但必须有对账补偿

// 中间业务层 — BASE 的典型应用
订单状态同步、物流追踪、评价系统：
  订单创建成功 → 异步通知物流系统
  物流状态变化 → 异步更新订单页面
  // 用户看到的状态可能有几秒延迟，完全可接受

// 边缘业务层 — 纯 AP
推荐列表、搜索排序、广告曝光：
  推荐算法算出的结果缓存 5 分钟
  新上架商品可能在 5 分钟后出现在推荐中
  // 不影响用户体验，反而降低系统压力

// CP 阵营 —— 数据一致性优先
ZooKeeper  — 配置中心、分布式锁、Leader 选举（ZAB）
etcd       — K8s 元数据存储、服务发现（Raft）
HBase      — 大数据强一致存储（依赖 ZK）
TiKV       — 分布式 KV，金融级强一致（Raft）

// AP 阵营 —— 可用性优先
Eureka     — Spring Cloud 服务注册发现（P2P 复制）
Cassandra  — 大规模写入（Gossip + 可调一致性）
DynamoDB   — AWS 托管 NoSQL（向量时钟 + 最终一致）
Redis Cluster — 主从异步复制，故障时可能丢少量写入

// 混合/可配置
Consul     — 默认 CP（Raft），但也支持 AP 模式
Nacos      — 临时实例用 AP（Distro），持久实例用 CP（Raft）
MongoDB    — 默认最终一致，可配置 w=majority 达到强一致

// 场景一：秒杀库存扣减
分析：库存数据不一致 → 超卖 → 资损
结论：选 CP 方向，用 Redis 原子扣减 + 数据库最终一致

// 场景二：用户注册
分析：注册成功后立即登录，如果注册数据和登录数据不一致 → 用户体验差
结论：选 CP 方向，注册写入主库后同步完成再返回

// 场景三：朋友圈/动态
分析：发布动态后朋友看到的时间有先后 → 完全可接受
结论：选 AP 方向，异步推送到粉丝的 Feed 列表

// 场景四：分布式配置中心
分析：配置变更必须所有节点一致生效 → 否则行为不可预测
结论：选 CP 方向，用 ZooKeeper/Nacos 持久实例

// 场景五：商品详情页浏览
分析：价格、描述等数据变更，用户看到旧版 → 影响不大
结论：选 AP 方向，缓存 + 异步更新