Redis 高可用：主节点挂了以后谁接管¶

假设登录会话保存在 Redis 中，单个 Redis 挂了，用户就可能无法登录。加一个副本能保留数据，但还需要有人判断主节点故障、选择新主节点，并告诉应用新的地址。

先把三件事分开：复制负责多一份数据，故障切换负责恢复服务，持久化与备份负责重启恢复及历史恢复。

主从复制是基础¶

应用写入 → 主节点 A
             ├─ 异步复制 → 副本 B
             └─ 异步复制 → 副本 C

副本初次连接可能需要全量同步；断线恢复时，如果复制历史还在 backlog 中，可以增量追赶。全量同步会消耗网络、CPU、内存和磁盘资源，不能只看最终是否连接成功。

复制通常是异步的：A 刚告诉应用“写成功”，数据还没到 B，A 就故障了，此时提升 B 可能丢失这次写入。多副本并不等于零丢失。Redis 复制说明

Sentinel：有人负责观察和换主¶

Sentinel 是独立的监控与故障切换进程。常见起点是一个主节点、两个副本，以及跨故障域部署的三个 Sentinel；它们可以共用部分主机，但不能全放在同一个故障域。

Sentinel 1、2、3 → 监控主从状态、协商切换
应用 → 向 Sentinel 查询当前主节点 → 直接连接 Redis

Sentinel 不代理业务流量。应用必须使用支持 Sentinel 的客户端，配置多个 Sentinel 地址和主节点组名；如果仍把 A 的 IP 写死，后台切主成功，应用也可能连不上。

A 故障后的过程¶

一个 Sentinel 在规定时间内联系不到 A，先认为它主观下线。
达到配置的 quorum 数量后，形成客观下线判断。
故障切换还需要 Sentinel 多数派授权，由选出的执行者推进。
根据副本资格、优先级和复制进度等选择新主节点，让其他副本跟随它。
客户端重新发现主节点，断开的连接重新建立。

quorum 与多数派是两个条件。例如三个 Sentinel、quorum 为 2，两个正常工作时通常可以推进切换；仅剩一个时，即使降低 quorum，也不能靠它绕过多数派要求。切换期间会有错误和重连，不能承诺请求完全无感。Sentinel 机制

看懂一段配置¶

下面是隔离实验环境的核心片段，示例 IP 需要替换；认证、文件权限和其他配置按环境补齐。三个 Sentinel 都监控同一组，配置文件需要可写以保存运行状态。

port 26379
sentinel monitor cache-main 10.10.0.11 6379 2
sentinel down-after-milliseconds cache-main 5000
sentinel failover-timeout cache-main 60000
sentinel parallel-syncs cache-main 1

cache-main 是应用查询的组名；最后的 2 是 quorum。5 秒是判定无响应的时间，不是整个切换必定在 5 秒内完成。parallel-syncs 控制切换后同时重新跟随新主的副本数，避免所有副本一起同步带来压力。

redis-cli -h <sentinel地址> -p 26379 SENTINEL get-master-addr-by-name cache-main
redis-cli -h <sentinel地址> -p 26379 SENTINEL replicas cache-main
redis-cli -h <sentinel地址> -p 26379 SENTINEL CKQUORUM cache-main
redis-cli -h <redis地址> -p 6379 INFO replication

有认证时用对应 ACL/凭据连接；不要将密码直接留在共享命令历史中。

Cluster：数据也需要分散到多台机器¶

Sentinel 的一组主从保存同一份数据，不能把一个主节点的写入或数据容量分摊给多个主节点。需要分片时可以使用 Redis Cluster。

Cluster 把 key 分配到 16384 个哈希槽，多个主节点各负责部分槽，每个主节点可配副本。常见高可用起点是三主三副本，并将每组主副本放在不同主机。

Cluster 客户端
  ├─ 分片 A：主 A → 副本 A'
  ├─ 分片 B：主 B → 副本 B'
  └─ 分片 C：主 C → 副本 C'

客户端维护槽与节点的对应关系，并处理 MOVED、迁移期间的 ASK 等重定向。Cluster 自己协调故障切换，不需要再给它加 Sentinel。没有合格副本接管、失去多数主节点连通性或槽不可服务时，会影响可用性；具体影响范围还取决于完整槽覆盖等配置。Cluster 规范

对应用有什么影响¶

需要 Cluster 客户端。多 key 命令、事务和脚本涉及的 key 通常要在同一槽，例如 user:{1005}:profile 与 user:{1005}:session 用相同 hash tag 定位到同一槽。

不要把所有 key 都加上同一个 tag，这会把数据重新挤到一个分片。单个热点 key 也不会因为加了节点就自动拆开，需要应用侧缓存、限流或数据结构调整。

redis-cli -c -h <cluster节点地址> -p 6379 CLUSTER INFO
redis-cli -c -h <cluster节点地址> -p 6379 CLUSTER NODES

容器/NAT 环境要特别检查通告地址：客户端和各节点必须能够访问这些地址。连得上第一个节点，但重定向到不可达的地址，是常见故障。

三种方案怎么选¶

方案	自动切主	分散数据和写入	适合什么
普通主从	需另行实现	否	已有外部管理机制，或实验学习
主从 + Sentinel	是，满足仲裁及副本条件时	否	单主容量够用，重点需要自动恢复
Cluster + 副本	是，满足集群条件时	是	单主容量或写入能力不足，应用可接受分片约束

数据可靠性与切换速度如何取舍¶

min-replicas-to-write 与 min-replicas-max-lag 可以在副本不足或延迟过大时拒绝写入，减少孤立主节点继续接受写入的风险；代价是网络故障时可写性下降，它们不提供严格同步提交。

WAIT 可以等待先前写入获得指定数量副本的确认，但应用需要处理返回值和超时，它也不能把异步复制变成强一致系统。对于不能接受重复或丢失的业务，应保留幂等、持久记录和对账机制。

怎样证明高可用真的有效¶

在测试环境持续读写带序号的数据，记录成功响应和耗时，再分别模拟主节点退出、主机故障、网络隔离和副本延迟。观察新主是谁、应用多久恢复、已确认写入是否缺失，以及旧主恢复后能否正确跟随。

同时关注持久化失败、复制延迟、内存上限、淘汰数量及故障域分布。只看到进程自动重启，或者管理端显示切主成功，还不能说明业务恢复成功。