Redis 高可用架构：主从复制与哨兵机制

┌──────────────────────────────────────────────────────────────────┐
│                         Client / Application                      │
└────────────┬──────────────┬──────────────┬────────────────────────┘
             │ 写入         │ 读取         │ 读取
             ▼              ▼              ▼
       ┌─────────┐    ┌─────────┐    ┌─────────┐
       │ Master  │───▶│ Slave 1 │    │ Slave 2 │
       │  (RW)   │    │  (RO)   │    │  (RO)   │
       └─────────┘    └─────────┘    └─────────┘
             │              │              │
             │     RDB / AOF 命令流        │
             └──────────────┴──────────────┘

Slave                                     Master
  │                                          │
  │──── PSYNC ? -1 ────────────────────────▶│  ① 建立连接，请求全量同步
  │                                          │
  │◀─── FULLRESYNC runid offset ───────────│  ② 返回 runid + 偏移量
  │                                          │
  │                                          │
  │◀─── RDB 文件 ──────────────────────────│  ③ 发送 RDB 快照
  │    (replication buffer 缓存期间新写命令)  │
  │                                          │
  │◀─── 缓冲命令 ──────────────────────────│  ④ 发送增量命令
  │                                          │
  │◀═══ 持续命令传播 ═══════════════════════│  ⑤ 异步复制后续写命令
  │                                          │

Slave → Master:  PSYNC ? -1
                  │ 表示：我是新来的，没有 runid，没有 offset
Master → Slave:   FULLRESYNC <runid> <offset>
                  │ 表示：必须全量同步，我的 runid 是 xxx，当前 offset 是 nnn

┌──────────────┐                          ┌──────────────┐
│    Master    │                          │    Slave     │
│              │                          │              │
│ 1. BGSAVE    │                          │  等待数据     │
│    ↓         │                          │              │
│ 2. 写 RDB 文件│                          │              │
│    │         │                          │              │
│    │ 期间新写入的命令                      │              │
│    │ 暂存在                              │              │
│    │ replication buffer 中              │              │
│    │                                    │              │
│ 3. 发送 RDB ─────────────────────────▶   │ 4. 清空旧数据 │
│                                         │ 5. 加载 RDB   │
└──────────────┘                          └──────────────┘

无盘复制流程：

Master                                     Slave1  Slave2
  │                                           │       │
  │ BGSAVE（仅 fork，不写磁盘）                 │       │
  │                                           │       │
  │ 等待 repl-diskless-sync-delay 秒           │       │
  │                                           │       │
  ├── socket ────────────────────────────────▶│       │
  ├── socket ─────────────────────────────────────────▶│
  │  （并发发送同一份 RDB 到多个从节点）         │       │
  │                                           │       │

Slave                                     Master
  │                                          │
  │── PSYNC <runid> <offset> ──────────────▶│  ① 带上已知的 runid 和 offset
  │                                          │
  │                                      ┌───┴──────────────┐
  │                                      │ 检查 runid 是否匹配│
  │                                      │ 检查 offset 是否  │
  │                                      │ 在 backlog 范围内  │
  │                                      └───┬──────────────┘
  │                                          │
  │◀── CONTINUE ───────────────────────────│  ② 同意增量同步
  │                                          │
  │◀── backlog 中 offset 之后的命令 ────────│  ③ 发送差异数据
  │                                          │
  │◀═══ 持续命令传播 ═══════════════════════│  ④ 恢复正常复制
  │                                          │

环形缓冲区示意（默认 1MB）：

         ┌─────────────────────────┐
         │  cmd_1 │ cmd_2 │ cmd_3 │
         ▼        │        │        │
  ┌──────┴──────┐ │ ┌──────┴──────┐ │
  │             │ │ │             │ │
  │    ...      │ │ │   已发送     │ │
  │             │ │ │   命令...    │ │
  │             │ ▼ │             │ ▼
  │    尚未发送  │   └─────────────┘
  │    的命令    │
  │             │  ────── offset 移动方向 ──────▶
  └─────────────┘
  
  写入指针 ↑
  └─ 主节点每产生一条写命令，offset+1，写入缓冲区当前位置
  
  如果写入速度过快，新数据会覆盖旧数据（环形覆盖）
  从节点 offset 对应的数据被覆盖 → 无法增量同步 → 回退到全量同步

repl-backlog-size = 断连秒数 × 每秒写入量 × 2

例如：
  预期最大断连时间 60 秒
  每秒写入 1000 条命令（平均每条 256 字节）
  → size = 60 × 1000 × 256 × 2 = 30,720,000 ≈ 30MB

              ┌─────────┐
              │  Master  │
              └────┬─────┘
          ┌────────┼────────┐
          ▼        ▼        ▼
     ┌─────────┐┌─────────┐┌─────────┐
     │ Slave 1 ││ Slave 2 ││ Slave 3 │
     └─────────┘└─────────┘└─────────┘

              ┌─────────┐
              │  Master  │
              └────┬─────┘
                   │ 复制
                   ▼
              ┌─────────┐
              │ Slave 1 │ ← 直接从主节点复制
              └────┬─────┘
                   │ 复制
                   ▼
              ┌─────────┐
              │ Slave 2 │ ← 从 Slave 1 复制
              └────┬─────┘
                   │ 复制
                   ▼
              ┌─────────┐
              │ Slave 3 │ ← 从 Slave 2 复制
              └─────────┘

主节点处理过期键的方式：
  1. 惰性删除：客户端访问过期键时删除
  2. 定期删除：每 100ms 随机抽取键检查并删除

  → 无论哪种方式，主节点都会在删除后生成 DEL 命令
  → DEL 命令被写入 AOF 并传播给所有从节点
  → 从节点执行 DEL 命令删除对应键

┌─────────────────────────────────────────────────────────────┐
│                     Redis Sentinel 集群                       │
│                   （最少 3 个，推荐奇数个）                    │
├───────────────┬───────────────┬───────────────────────────────┤
│   ① 监控       │ ② 自动故障转移  │ ③ 配置提供者                  │
│   Monitoring  │  Auto Failover│  Config Provider             │
│               │               │                              │
│ 每 1s PING    │ 检测主节点下线  │ 客户端通过哨兵查询             │
│ 每 2s INFO    │ 选举新主节点   │ 当前主节点地址                 │
│ 哨兵间发现     │ 自动切换拓扑   │                              │
├───────────────┴───────────────┴───────────────────────────────┤
│                      ④ 通知 (Notification)                   │
│      故障转移结果通知客户端，支持 Pub/Sub 频道订阅              │
└─────────────────────────────────────────────────────────────┘

                  ┌──────────────────────────┐
                  │       Client / App        │
                  │   (Sentinel-aware 客户端)  │
                  └──────────┬───────────────┘
                             │ ① 问：当前 Master 在哪？
                             ▼
         ┌───────────────────────────────────────┐
         │          Sentinel 集群 (≥3)            │
         │                                       │
         │  ┌───────────┐  ┌───────────┐  ┌───────────┐
         │  │ Sentinel 1│  │ Sentinel 2│  │ Sentinel 3│
         │  │ :26379    │  │ :26380    │  │ :26381    │
         │  └─────┬─────┘  └─────┬─────┘  └─────┬─────┘
         │        │              │              │
         └────────┼──────────────┼──────────────┼────┘
                  │  监控/管理    │              │
         ┌────────┴──────────────┴──────────────┴────┐
         │              Redis 数据节点                  │
         │                                            │
         │  ┌──────────┐   ┌──────────┐  ┌──────────┐ │
         │  │  Master  │──▶│ Slave 1  │  │ Slave 2  │ │
         │  │  :6379   │   │  :6380   │  │  :6381   │ │
         │  └──────────┘   └──────────┘  └──────────┘ │
         └─────────────────────────────────────────────┘

Sentinel 发现新从节点流程：

  Sentinel ── PING ──▶ Master
  Sentinel ── INFO ──▶ Master  → 返回 connected_slaves 列表
                                → Sentinel 自动添加对从节点的监控
                                → 无需手动配置从节点地址

哨兵间自动发现流程：

  Sentinel-1 ── PUBLISH __sentinel__:hello ──▶ Master
  Sentinel-2 ◀── SUBSCRIBE __sentinel__:hello ── Master
  Sentinel-2 从消息中得知 Sentinel-1 的 IP/端口
  两个哨兵建立直连关系
  
  → 无需手动配置其他哨兵的地址

故障转移全流程：

 1. 哨兵集群投票选出执行故障转移的 Leader Sentinel
 2. Leader Sentinel 从所有从节点中选举新主节点
 3. Leader Sentinel 向新主节点发送 REPLICAOF NO ONE
 4. Leader Sentinel 向其余从节点发送 REPLICAOF new_master_ip new_master_port
 5. 持续监控旧主节点，一旦恢复则将其变为新主节点的从节点

判定流程：

  哨兵 ── PING ──▶ 节点
       ◀── 无响应 ── 持续 down-after-milliseconds 毫秒
       → 标记该节点为 SDOWN（该哨兵的主观判断，不代表集群共识）

判定流程：

  Sentinel-1 发现 Master 为 SDOWN
     │
     │ 向其他哨兵发送: SENTINEL is-master-down-by-addr <ip> <port>
     │
     ├── Sentinel-2: "是的，我也认为 Master 下线了"
     ├── Sentinel-3: "是的，我也认为 Master 下线了"
     │
     └── 收集到 ≥ quorum 张赞成票
        → 标记该节点为 ODOWN
        → 启动故障转移流程

情景：3 个哨兵，quorum = 1

  如果 Sentinel-1 与主节点网络不通（其他正常）
  Sentinel-1 认为主节点 SDOWN
  仅需 1 票即可达到 quorum → 标记 ODOWN
  Sentinel-1 发起故障转移，但无法获得 majority（需要 2 票）
  → 故障转移卡住，但集群已进入不稳定的中间状态

排序优先级（从高到低）：

  ┌─ 1. 排除不健康节点
  │      ├── 处于 SDOWN / ODOWN 状态的节点
  │      ├── 断连时间超过 down-after-milliseconds * 10 的节点
  │      └── 与主节点断开连接超过一定时间的节点
  │
  ├─ 2. replica-priority（越小越优先，0 = 永不参选）
  │
  ├─ 3. 复制偏移量最大（数据最新）
  │
  ├─ 4. runid 字典序最小（相同条件下确定性选择）
  │
  └─ 选出新主节点

┌─ 阶段一：Leader 选举 ──────────────────────────────────────┐
│                                                             │
│  发现 ODOWN 的哨兵向其他哨兵发投票请求                        │
│  → 每个哨兵在同一个 epoch 只能投一票                          │
│  → 获得 majority 票的哨兵成为 Leader                         │
│  → 使用 Raft-like 协议，epoch 保证同一轮只有一位 Leader        │
│                                                             │
└─────────────────────────────────────────────────────────────┘
     │
     ▼
┌─ 阶段二：选举新主节点 ───────────────────────────────────────┐
│                                                             │
│  Leader Sentinel 按选举规则（优先级→偏移量→runid）选出最优从节点│
│                                                             │
└─────────────────────────────────────────────────────────────┘
     │
     ▼
┌─ 阶段三：升级新主节点 ────────────────────────────────────────┐
│                                                             │
│  Leader → 新主节点:  REPLICAOF NO ONE                        │
│  新主节点升级为独立节点，可接受读和写                          │
│                                                             │
└─────────────────────────────────────────────────────────────┘
     │
     ▼
┌─ 阶段四：重定向其他从节点 ────────────────────────────────────┐
│                                                             │
│  Leader → 其余从节点: REPLICAOF <new_master_ip> <port>       │
│  使用 parallel-syncs 控制同时同步的从节点数量                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘
     │
     ▼
┌─ 阶段五：监控旧主节点 ────────────────────────────────────────┐
│                                                             │
│  旧主节点恢复后：                                            │
│  Sentinel 检测到旧主节点重新上线                               │
│  → 向旧主节点发送 REPLICAOF <new_master_ip> <port>           │
│  → 旧主节点降级为新主节点的从节点                              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

哨兵间通过主节点的 __sentinel__:hello 频道实现自动发现：

┌──────────────┐                          ┌──────────────┐
│  Sentinel 1  │                          │  Sentinel 2  │
│  192.168.1.1 │                          │  192.168.1.2 │
└──────┬───────┘                          └──────┬───────┘
       │                                         │
       │ 每 2 秒 PUBLISH                        │ 每 2 秒 PUBLISH
       │ __sentinel__:hello                     │ __sentinel__:hello
       │ "192.168.1.1, 26379, ..."              │ "192.168.1.2, 26379, ..."
       │                                         │
       ▼                                         ▼
┌─────────────────────────────────────────────────────────┐
│                    Master (:6379)                        │
│                   __sentinel__:hello                     │
│                        频道                              │
└─────────────────────────────────────────────────────────┘
       │                                         │
       │ SUBSCRIBE                              │ SUBSCRIBE
       │ __sentinel__:hello                     │ __sentinel__:hello
       │                                         │
       ▼ 收到 Sentinel 2 的信息                   ▼ 收到 Sentinel 1 的信息
  Sentinel 1 自动添加                     Sentinel 2 自动添加
  Sentinel 2 到已知哨兵列表                 Sentinel 1 到已知哨兵列表

              ┌─────────────┐
              │  正常运行    │ 每 1s PING, 每 2s INFO
              └──────┬──────┘
                     │ 检测到 SDOWN
                     ▼
              ┌─────────────┐
              │  询问其他     │ 发送 SENTINEL is-master-down-by-addr
              │  哨兵意见    │
              └──────┬──────┘
                     │ 达到 quorum
                     ▼
              ┌─────────────┐
              │  Leader选举  │ Raft-like 投票
              └──────┬──────┘
                     │ 当选 Leader
                     ▼
              ┌─────────────┐
              │  执行故障     │ 选举新主节点、重配置拓扑
              │  转移       │
              └──────┬──────┘
                     │ 故障转移完成
                     ▼
              ┌─────────────┐
              │  恢复正常     │ 继续监控（包括旧主节点恢复）
              │  监控       │
              └─────────────┘

触发条件：
  - 两次定时任务之间的实际时间差与预期差 > 2 秒
  - 常见原因：NTP 同步导致时钟跳变、虚拟机暂停/恢复

TILT 模式下的行为：
  - 继续收集信息（PING、INFO、Pub/Sub）但不做任何决策
  - 不发起故障转移
  - 不参与投票
  - 30 秒后退出 TILT 模式（如果时钟恢复正常）

查看 TILT 状态：
  redis-cli -p 26379 INFO sentinel | grep tilt
  # tilt:0 → 正常
  # tilt:1 → TILT 模式

选举过程：

  1. 发现 ODOWN 的哨兵增加自己的 current_epoch
  2. 向其他哨兵发送投票请求（包含新 epoch）
  3. 每个哨兵在每个 epoch 只能投一票（先到先得）
  4. 获得 ≥ majority 票数的哨兵成为 Leader
  5. 如果超时未选出 Leader，等待 failover-timeout 后重新选举

关键属性：
  - epoch 是单调递增的逻辑时钟
  - 每个 epoch 最多产生一个 Leader
  - 确保故障转移的唯一性

客户端启动
    │
    ▼
随机连接一个 Sentinel ────▶ SENTINEL get-master-addr-by-name "mymaster"
    │                                   │
    │                           返回 Master IP:Port
    │                                   │
    ▼                                   ▼
直接连接 Master 并执行命令 ◀────────────┘
    │
    │ 同时 SUBSCRIBE +switch-master 频道
    │
    ▼
收到主节点切换通知
    │
    ▼
断开旧 Master ──▶ 重新查询 Sentinel ──▶ 连接新 Master

推荐的物理部署拓扑（6 台机器）：

    ┌────────────────────────────────────────────────────────┐
    │  机器 1         机器 2         机器 3                   │
    │  Sentinel 1      Sentinel 2     Sentinel 3             │
    │  端口 26379      端口 26379     端口 26379              │
    └────────────────────────────────────────────────────────┘
    
    ┌────────────────────────────────────────────────────────┐
    │  机器 4         机器 5         机器 6                   │
    │  Redis Master   Redis Slave 1  Redis Slave 2           │
    │  端口 6379      端口 6379      端口 6379                │
    └────────────────────────────────────────────────────────┘

场景：4 个哨兵，majority = ceil(4/2) = 2

  如果网络分区将哨兵分成 2-2：
  - 两边的 Leader 候选人各得 2 票（自己的 + 另一票）
  - 但需要 > 2 票才能成为 Leader
  - 故障转移无法完成

结论：哨兵数量必须为奇数（3、5），不要用偶数。

设置过短（如 1 秒）：
  → 偶发网络抖动被误判为节点故障
  → 触发不必要的故障转移
  → 故障转移期间可能有数据丢失（异步复制未完成）

设置过长（如 5 分钟）：
  → 真实故障恢复慢
  → 服务不可用时间过长

建议：生产环境 15-30 秒

主节点每新增一个从节点：
  - fork 一个子进程进行 BGSAVE
  - fork 操作本身会阻塞主线程（fork 时间与内存成正比，大内存实例尤为严重）
  - CPU 和内存使用增加
  
缓解：
  - 使用 repl-diskless-sync 减少磁盘 I/O
  - 使用链式复制分摊压力
  - 多个从节点交错启动（避免同时全量同步）

计算公式：
  安全内存 = Redis 数据大小 + fork 期间预期写入量 + 系统预留

风险场景：
  - Redis 使用 8GB 内存，宿主机共 16GB
  - BGSAVE 期间有 4GB 写入
  - 内存使用 = 8GB (现有) + 4GB (COW 复制) = 12GB
  - 加上系统开销，可能触发 OOM Killer

缓解：
  - 宿主机预留足够内存（至少 Redis 数据大小 × 1.5）
  - 避免在写入高峰时段执行 BGSAVE
  - 使用 `vm.overcommit_memory=1` 配合 swap

原因：runid 是 Redis 启动时随机生成的，重启后必然变化。

影响：
  - 从节点发现 runid 变化 → 无法增量同步 → 触发全量同步
  - 全量同步可能耗时数十分钟（取决于数据量）
  - 期间从节点可能不可用（取决于 replica-serve-stale-data 设置）

缓解：
  - 计划内重启时先执行故障转移，让哨兵将主节点切走
  - 增大 repl-backlog-size 无济于事（因为 runid 变了）
  - 从 Redis 7.0 开始，可以通过 replication-pair-id 减少此问题

问题表现：
  - 故障转移后，客户端仍连旧主节点
  - 旧主节点回复 READONLY 错误（已降级为从节点）
  - 客户端写入失败

原因：
  - 客户端未使用哨兵模式
  - 客户端未订阅 +switch-master 频道
  - 客户端 DNS 缓存了旧地址

解决：
  - 使用 Sentinel-aware 客户端（go-redis FailoverClient）
  - 客户端需要 SUBSCRIBE +switch-master
  - 编写应用层重连逻辑

为什么需要独立备份：
  - 误操作（DROP / FLUSHALL / DEL）会同步到从节点
  - 应用 Bug 导致的逻辑损坏会传播
  - 无法做到时间点恢复 (PITR)

正确的备份策略：
  - 定期在从节点上执行 BGSAVE / AOF 备份到外部存储
  - 保留多份历史备份（至少过去 7 天）
  - AOF + RDB 混合持久化
  - 异地/多可用区存放备份文件

故障转移后，新主节点需要向所有从节点同步数据：

  parallel-syncs = 1:
    Slave 1 同步完成 → Slave 2 开始同步 → Slave 3 开始同步
    主节点负担可控，从节点逐个恢复
    
  parallel-syncs = N (如 10):
    10 个从节点同时发起全量同步
    主节点需要 fork 10 个子进程进行 BGSAVE
    → 主节点 CPU 飙升、内存耗尽
    → 可能引发新的故障转移
    → 雪崩

建议: parallel-syncs 设为 1，宁可慢一点，不能压垮新主节点