学完这篇，你能根据业务量级选对 Redis 高可用方案，并照着命令把主从复制、哨兵、Cluster 三套环境实际搭起来。
第一步：先认清三种方案的分工
- 主从复制：一台主节点写，多台从节点读。只解决读扩展和数据冗余，主挂了不会自动切换，得人工处理。
- 哨兵（Sentinel）：在主从基础上加一组监控进程，主节点宕机后自动选新主、改配置、通知客户端。数据仍在单个主节点上，容量受单机内存限制。
- Cluster：数据分片到多个主节点（16384 个槽位），每片自带从节点。既解决容量瓶颈也解决写扩展，代价是客户端必须支持集群模式，多 key 操作受限。
判断标准很简单：数据量能塞进一台机器、只想避免宕机 → 哨兵；数据量或写入量一台机器扛不住 → Cluster。
第二步：搭主从复制
准备两台机器，主节点 192.168.1.10，从节点 192.168.1.11。
主节点 redis.conf 建议加：
bind 0.0.0.0
requirepass yourpassword
masterauth yourpassword
appendonly yes
从节点只需再加一行：
replicaof 192.168.1.10 6379
replica-read-only yes
两台分别启动后，在主节点执行 INFO replication，看到 connected_slaves:1 即为成功；在从节点执行同一条命令，master_link_status:up 说明链路正常。
注意：requirepass 和 masterauth 两个都要配。只配 requirepass 时，从节点连主节点会报 NOAUTH，master_link_status 会一直是 down。
不改配置文件也可以在线切换：从节点执行 REPLICAOF 192.168.1.10 6379；要把它提升为主节点，执行 REPLICAOF NO ONE。
第三步：搭哨兵实现自动故障转移
哨兵节点至少 3 个（奇数，且不要和 Redis 数据节点混部在同一台）。每台的 sentinel.conf 内容基本一致：
port 26379
daemonize yes
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel auth-pass mymaster yourpassword
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
sentinel monitor 最后的 2 是 quorum，表示至少 2 个哨兵认为主节点客观下线才触发选举，一般设为 哨兵数/2 + 1。
启动：redis-sentinel /etc/redis/sentinel.conf（或 redis-server /etc/redis/sentinel.conf --sentinel）。
验证：redis-cli -p 26379 SENTINEL masters 能看到主节点状态，SENTINEL get-master-addr-by-name mymaster 返回当前主节点地址。手动 SHUTDOWN 主节点，等约 30 秒后再查一次，地址应该已经变成从节点 IP。
注意：哨兵运行期间会自动改写 sentinel.conf（记录发现的从节点和状态）。配置文件所在目录必须可写，否则选举结果无法落盘。另外 sentinel monitor 里建议填内网 IP 而不是 127.0.0.1，多机部署时填本机会导致互相找不到。
注意：主节点恢复后会以从节点身份重新加入，不要手动再改配置，交给哨兵管理。
第四步：搭 Cluster 分片集群
Cluster 至少 3 主 3 从，共 6 个节点。以 7000-7005 端口为例，每个节点的 redis.conf：
port 7000
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 15000
appendonly yes
bind 0.0.0.0
requirepass yourpassword
masterauth yourpassword
protected-mode no
6 个节点逐个启动后，用一条命令建集群（--cluster-replicas 1 表示每个主配 1 个从）：
redis-cli -a yourpassword --cluster create \
192.168.1.10:7000 192.168.1.10:7001 192.168.1.10:7002 \
192.168.1.11:7003 192.168.1.11:7004 192.168.1.11:7005 \
--cluster-replicas 1
输入 yes 确认槽位分配方案。检查：redis-cli -a yourpassword --cluster check 192.168.1.10:7000，应显示 [OK] All 16384 slots covered；或者连上任一节点执行 CLUSTER INFO 看 cluster_state:ok。
注意：Cluster 模式下 SELECT 切换数据库不可用（只有 db 0）；涉及多个 key 的命令（MGET、MSET、SUNION、事务等）要求所有 key 落在同一个槽，跨槽会报 CROSSSLOT。解决办法是在 key 里加 hashtag，例如 user:{1001}:name 和 user:{1001}:age，花括号内相同就会被分到同一槽。
注意：连接集群必须用集群模式客户端（redis-cli -c 或客户端开启 cluster 选项），普通连接遇到不属于当前节点的 key 会返回 MOVED 重定向错误，不会自动跳转。
第五步：客户端侧别漏掉的配置
- 哨兵方案：客户端配置的是哨兵地址列表，不是 Redis 地址。以 Spring Boot 为例，配
spring.redis.sentinel.master=mymaster 和 spring.redis.sentinel.nodes=ip1:26379,ip2:26379,ip3:26379。
- Cluster 方案：配
spring.redis.cluster.nodes=ip1:7000,ip2:7000,...，客户端会自动拉取槽位映射。
- 无论哪种，密码都要同时填在连接密码和哨兵/集群认证参数里，否则切换后新主鉴权失败。
小结
- 主从只负责冗余和读扩展，故障转移靠人工；哨兵在它之上补上自动选主；Cluster 再加分片解决容量问题。
- 主从配置的关键是
replicaof + masterauth 两个都要有，用 INFO replication 中 master_link_status:up 验收。
- 哨兵至少 3 个、quorum 过半、配置目录可写，三条不满足就会切换失败。
- Cluster 至少 3 主 3 从，16384 槽必须全覆盖，多 key 操作用
{hashtag} 保证同槽。
- 客户端配的是哨兵/集群入口，不是单个 Redis 地址，密码要覆盖切换后的新主。
正式会员
认证极客
见习用户
