redis哨兵集群部署核心是“1主2从3哨兵”结构，需独立配置主节点（requirepass、appendonly）、从节点（replicaof、masterauth）、哨兵（sentinel monitor、auth-pass、down-after-milliseconds），通过docker-compose统一网络与服务名通信，依赖docker dns解析，启动后验证容器状态、哨兵监控信息及故障转移能力。
用 Docker Compose 部署 Redis 哨兵集群，核心是搭好“1 主 2 从 3 哨兵”结构，并确保各节点能互相发现、认证和协同选举。不靠复杂脚本，靠配置驱动，5 分钟可拉起可观测的高可用环境。
准备基础配置文件
每个角色需独立配置，避免混用：
-
主节点：关闭保护模式、开启 AOF 持久化、设密码（
requirepass），不配replicaof -
从节点：指定主节点地址（如
replicaof redis-master 6379）、设相同密码（masterauth和requirepass）、同样开启 AOF -
哨兵节点：每份
sentinel.conf都要写明监控目标（sentinel monitor mymaster redis-master 6379 2）、认证密码（sentinel auth-pass mymaster 123456）、下线判定时长（如down-after-milliseconds设为 5000）
编写 docker-compose.yml
所有服务共用同一网络，便于容器间通过服务名通信：
- 主从 Redis 容器用
redis:7.0或redis:6.2-alpine镜像，命令行直接传参启动（如--appendonly yes） - 哨兵容器挂载对应
sentinel.conf，并用redis-sentinel /etc/sentinel.conf启动 - 确保
depends_on仅用于启动顺序控制（如从节点依赖主节点），不解决网络就绪问题；实际通信靠 Docker 内置 DNS 自动解析服务名
启动与验证流程
执行 docker-compose up -d 后，分三步确认是否正常：
- 查容器状态：
docker-compose ps确保全部为Up - 进哨兵容器执行
redis-cli -p 26379 sentinel master mymaster，看返回中"num-slaves":2和"quorum":2是否匹配 - 手动停主节点：
docker-compose stop redis-master，等 10 秒后运行redis-cli -p 26379 sentinel get-master-addr-by-name mymaster，应返回新主 IP 和端口
常见坑与绕过方法
多数失败源于配置细节或网络认知偏差：
- 哨兵连不上主节点？检查
sentinel monitor中的 host 是否用服务名（如redis-master），而非127.0.0.1或宿主机 IP - 故障转移不触发？确认哨兵配置里的
quorum值 ≤ 哨兵总数，且至少两个哨兵能互相通信（可通过redis-cli -p 26379 sentinel sentinels mymaster查已知哨兵列表） - 客户端连不上新主？应用必须支持哨兵自动发现机制（如 Jedis 的
JedisSentinelPool），不能硬编码旧主地址
