1. 结构图
先来看整体结构设计，三台物理机组成主从集群，图示如下：
其中 192.168.0.101 作为 Master，其余两台作为 Slave。这个经典的 Redis 主从架构既能有效分担读压力，又能通过 Sentinel 哨兵机制实现高可用故障转移。
2. Master 的 redis.conf 配置
Master 的配置直接贴出来，关键参数已经加了注释，但有几个地方值得单独拎出来强调一下：
# 开启守护模式 daemonize yes # 设置密码 requirepass redis # 指定数据存储目录 dir ./ # 每秒一次aof写 appendfsync everysec # 打开aof持久化 appendonly yes # 设置Master的密码（如果Master有密码的话） masterauth redis # 3.2之后新加特性，在没有配置密码和bind时启用保护机制 protected-mode no # 注释掉bind #bind 127.0.0.1
注意这里的 protected-mode no 是必须的，否则从机无法连接。另外 masterauth 必须与 requirepass 保持一致，否则后续主从切换时会引发认证失败。
3. Slave 的 redis.conf 配置
从机配置基本是 Master 的镜像，但多了两个关键项：
# 开启守护模式 daemonize yes # 设置密码 requirepass redis # 指定数据存储目录 dir ./ # 每秒一次aof写 appendfsync everysec # 打开aof持久化 appendonly yes # 指定所属的主机 slaveof 192.168.0.101 6379 # 设置Master的密码（如果Master有密码的话） masterauth redis # 指定从机"只读" slave-read-only yes # 3.2之后新加特性，在没有配置密码和bind时启用保护机制 protected-mode no # 注释掉bind #bind 127.0.0.1
slaveof 指定了主节点 IP 和端口，slave-read-only yes 确保从机不会意外写入数据。这两项配合起来，才是一个标准且安全的 Redis 主从复制配置。
4. 启动 Redis
配置完成后，分别启动三台 Redis 实例。启动后可以在 Master 上写入数据，然后到任意一台 Slave 上验证，数据应该已经自动同步过来。如果同步失败，大概率是 protected-mode 或 masterauth 设置不正确，按日志排查即可。
5. Sentinel.conf 配置
Sentinel 是负责监控和自动故障转移的核心组件，它的配置需要特别注意 quorum 和超时时间的设置：
# sentinel通讯端口 port 26379 # 3.2之后新加特性，在没有配置密码和bind时启用保护机制 protected-mode no # sentinel需要监控的master/slave信息，格式为sentinel monitor# 其中 应该小于集群中slave的个数，当失效的节点数超过了 ,则认为整个体系结构失效 sentinel monitor myMaster 192.168.0.101 6379 1 # sentinel auth-pass sentinel auth-pass myMaster redis # master被当前sentinel实例认定为失效的间隔时间，格式为sentinel down-after-milliseconds sentinel down-after-milliseconds myMaster 10000 # 当新master产生时，同时进行“slaveof”到新master并进行同步复制的slave个数 # 在slave执行slaveof同步时，将会终止客户端请求。 # 此值较大,意味着“集群”终止客户端请求的时间总和较大。 # 此值较小,意味着“集群”在故障转移期间，多个slave向客户端提供服务时仍然使用旧数据。 sentinel parallel-syncs myMaster 1 # failover过期时间。当failover开始后，在此时间内仍然没有触发任何failover操作，当前sentinel将会认为此次failover失败。 sentinel failover-timeout redisMaster 60000
这里 quorum 设置为 1，意味着只要有一个 Sentinel 认为 Master 挂了，就触发故障转移（前提是集群中总共部署了 3 个 Sentinel）。实际生产环境建议设为 2，以降低误判风险。
6. 启动 Sentinel
在三台机器上分别启动 Sentinel，启动后控制台会输出同步和监控信息。如果一切正常，能看到 Sentinel 相互发现，并确认 Master 状态。至此，Redis 高可用集群即搭建完成。
7. 注意事项
- protected-mode 必须设为 no：默认是 yes，会导致无法连接 Master。这个坑在 3.2 以上版本尤其常见，新手很容易忽略，务必检查。
- Slave 宕机时的通知：如果某台 Slave 挂了，Sentinel 会通知其他节点，但不会自动处理，只会持续尝试重连。因此运维人员需要关注监控告警，及时处理异常。
- Master 宕机后的自动切换：如果 Master 挂了，Sentinel 会在剩余的 Slave 中投票选举出一台新的 Master，并自动修改各节点的
redis.conf和sentinel.conf文件。最有趣的是，原先的 Master 如果重新启动，会被自动降级为 Slave，整个过程完全自动，无需人工干预，真正实现了 Redis 故障转移的自动化运维。
整体来说，这套配置足以应付大多数中小规模场景。如果还遇到问题，多半是网络、防火墙或者密码不一致导致的，按日志排查即可。
