Redis 主从复制原理与哨兵模式

主从复制架构：

        写操作
           ↓
    ┌──────────┐
    │  Master   │  ← 接收所有写请求
    └──┬───────┬─┘
       │       │  同步
   ┌───↓──┐ ┌──↓───┐
   │Slave1 │ │Slave2│  ← 处理读请求
   └───────┘ └──────┘

作用：
✅ 读写分离：读操作分散到多个从库
✅ 数据备份：每个从库都是完整数据副本
✅ 故障转移：从库可升级为主库
❌ 单点写入：只有主库能写入

触发条件：Slave 首次连接 / Slave 断开太久（repl_backlog 缓冲区不够）

全量同步流程：

  Slave → PSYNC <runid> <offset>   ← 发送复制命令
  Master → +FULLRESYNC <runid> <offset>  ← 返回完整重同步
  
  Master → RDB 文件（bgsave 生成）     ← 主库生成 RDB 快照
  Master → 缓冲区中的增量命令           ← RDB 生成期间的写命令
  
  Slave → 清空本地数据
  Slave → 加载 RDB 文件                  ← 恢复数据
  Slave → 执行增量命令                   ← 追平复制进度

触发条件：Slave 短时断开，offset 仍在 repl_backlog 缓冲区中

Master 端维护一个固定长度的环形缓冲区（repl_backlog）：
┌──────────────────────────────────────────────────────┐
│ runid=abc │ runid=abc │ runid=abc │ ... │ ← 循环使用 │
└──────────────────────────────────────────────────────┘
                                    ↑ offset 指针

Slave 记录自己消费到的 offset：
  Slave → PSYNC <master_runid> <slave_offset>
  如果 master_runid 匹配且 slave_offset 在缓冲区范围内
  → Master 只发送 slave_offset 之后的增量命令
  
否则 → 触发全量同步

问题：主库写 → 异步复制到从库 → 从库读取
                    ↓
            延迟：可能读到旧数据

原因：
1. 主库并发写入，从库串行重放（能力不对等）
2. 从库硬件差（CPU/磁盘）
3. 大事务（主库快，从库慢）

监控延迟：
  replica lagging seconds: 5   ← 从库延迟 5 秒

解决方案：
1. 关键读走主库（下单后立即查订单）
2. 监控延迟 > 阈值时降级读主库
3. 从库并行重放（replica-parallel-workers）

问题：一个 Master 有很多 Slave，同时做全量同步

Master
  │
  ├── Slave1 ──→ 全量同步（RDB bgsave）── CPU/IO 飙升
  ├── Slave2 ──→ 全量同步（RDB bgsave）── 再次 bgsave
  ├── Slave3 ──→ 全量同步（RDB bgsave）── ...
  └── Slave4 ──→ ...

解决：
1. 从库分批同步（修改 replicaof 的时间）
2. 使用 树莓派模式（中间层减少主库压力）
3. repl-diskless-sync yes（无磁盘，网络直接传 RDB）

主从复制的问题：
  Master 宕机 → 需要人工介入 → 手动选从库 → 修改从库配置 → 恢复写入
  
Sentinel 的职责：
  1. 监控：检测主库是否存活
  2. 通知：主库下线时通知应用
  3. 自动故障转移：自动选新主库，通知其他从库切换

第一阶段：主观下线（SDOWN）
  Sentinel 每秒向主库发送 PING
  如果超过 down-after-milliseconds 没响应
  → Sentinel 认为该库主观下线

第二阶段：客观下线（ODOWN）
  超过 quorum 个 Sentinel 都认为主库主观下线
  → 该主库进入客观下线状态

第三阶段：选举领头 Sentinel
  所有 Sentinel 参与 Raft 算法投票
  得票最多的成为领头 Sentinel
  负责执行故障转移

第四阶段：故障转移
  1. 从从库中选出一个新的主库
  2. 其他从库改为向新主库复制
  3. 旧主库重新上线后变为从库

Raft 简化版选举：

1. 每个 Sentinel 有一个 runid
2. 每个 Sentinel 向其他 Sentinel 发请求：
   SENTINEL is-master-down-by-addr
3. 得票最多的 Sentinel 当选领头
4. 领头 Sentinel 执行故障转移

投票规则：
  - 每个 Sentinel 只能投一票
  - 先到先得
  - 得票 > 总数/2 才算当选

选择优先级从高到低：

1. 优先级（replica-priority）最高的
   replica-priority 100  ← 默认值，越高越优先

2. offset 最接近主库的（数据最新）
   SELECT Replication offset 最接近

3. runid 最小的（字典序）
   纯理论上的 tie-breaker