既然我们在第 07 节已经用 Docker Desktop 完美搭建了主从集群，现在我们就顺水推舟，直接在同一个 Docker 网络里，把 3 个哨兵节点也部署起来。
📚 高级篇 11. 分布式缓存 - 搭建 Redis 哨兵集群 (Docker 实战版)
一、 架构规划
目前你的 Docker 里已经有了一个完美的底层基础：
redis-ms-net(专属局域网)redis-master(大哥)redis-slave-1,redis-slave-2(两个小弟)
现在，我们要向这个网络中安插 3 个“巡逻兵”（哨兵集群）：
- Sentinel 1： 容器名
redis-sentinel-1，宿主机端口27001 - Sentinel 2： 容器名
redis-sentinel-2，宿主机端口27002 - Sentinel 3： 容器名
redis-sentinel-3，宿主机端口27003
二、 核心实操：一键启动 3 个哨兵
请打开你的终端（PowerShell 或 CMD），依次复制并执行以下 3 条长命令。
(💡 原理揭秘：这三条命令会在容器内部自动创建 sentinel.conf 配置文件，并立刻启动哨兵进程，完美避开了 Windows 挂载文件的各种坑！)
1. 启动哨兵 1 号
Bash
docker run -d --name redis-sentinel-1 --network redis-ms-net -p 27001:26379 redis:latest sh -c "echo 'port 26379' > /tmp/sentinel.conf && echo 'sentinel monitor mymaster redis-master 6379 2' >> /tmp/sentinel.conf && echo 'sentinel down-after-milliseconds mymaster 5000' >> /tmp/sentinel.conf && redis-sentinel /tmp/sentinel.conf"
2. 启动哨兵 2 号
Bash
docker run -d --name redis-sentinel-2 --network redis-ms-net -p 27002:26379 redis:latest sh -c "echo 'port 26379' > /tmp/sentinel.conf && echo 'sentinel monitor mymaster redis-master 6379 2' >> /tmp/sentinel.conf && echo 'sentinel down-after-milliseconds mymaster 5000' >> /tmp/sentinel.conf && redis-sentinel /tmp/sentinel.conf"
3. 启动哨兵 3 号
Bash
docker run -d --name redis-sentinel-3 --network redis-ms-net -p 27003:26379 redis:latest sh -c "echo 'port 26379' > /tmp/sentinel.conf && echo 'sentinel monitor mymaster redis-master 6379 2' >> /tmp/sentinel.conf && echo 'sentinel down-after-milliseconds mymaster 5000' >> /tmp/sentinel.conf && redis-sentinel /tmp/sentinel.conf"
配置参数解析：
monitor mymaster redis-master 6379 2：监控名为mymaster的大哥（它的容器名是redis-master，端口6379），最后的2就是上节课讲的法定人数 (Quorum) ，即至少需要 2 个哨兵同意才能宣布大哥驾崩。down-after-milliseconds mymaster 5000：只要大哥 5 秒钟没回消息，就认为它主观下线（为了方便咱们一会做测试，时间设得很短，生产环境一般是 30000 即 30 秒）。
三、 验证哨兵是否正常上班
执行完毕后，你可以去 Docker Desktop 的 Containers 列表里看一眼，应该有 3 个绿色的 redis-sentinel 正在运行。
我们进入哨兵 1 号内部，看看它有没有发现大哥和小弟：
Bash
docker exec -it redis-sentinel-1 redis-cli -p 26379 info sentinel
正常情况下，你会看到最下面有这样一行输出：
master0:name=mymaster,status=ok,address=xxx.xxx.xxx.xxx:6379,slaves=2,sentinels=3
status=ok：说明大哥活得好好的。slaves=2：哨兵成功发现了 2 个小弟。sentinels=3：哨兵集群互相发现了彼此，组队成功！
四、 🌟 见证奇迹：高可用灾难演练 (面试吹水资本)
现在，激动人心的时刻到了！我们要亲手“拔掉”大哥的网线，看看系统会不会自动选出新皇！
第 1 步：人为制造宕机 (刺杀老大哥)
直接干掉 redis-master 容器：
Bash
docker stop redis-master
第 2 步：观察哨兵的疯狂反应
耐心等待 5 到 10 秒钟（因为我们设置了 5 秒超时），然后查看哨兵 1 号的实时日志：
Bash
docker logs redis-sentinel-1
(你会看到日志里疯狂输出 +sdown 主观下线、+odown 客观下线、+vote-for-leader 选举投票、最后 +switch-master 切换新大哥！这绝对是极其震撼的底层运作流！)
第 3 步：确认谁登基了新皇？
老大哥死了，现在 redis-slave-1 和 redis-slave-2 中必然有一个人被黄袍加身了。我们分别去它们身上查验身份：
查看 slave-1：
Bash
docker exec -it redis-slave-1 redis-cli info replication
查看 slave-2：
Bash
docker exec -it redis-slave-2 redis-cli info replication
你会发现：其中一个的 role 变成了 master，而另一个的 role 依然是 slave，并且它的 master_host 自动指向了刚才登基的那个新大哥！
第 4 步：老大哥诈尸还魂 (降级处理)
如果在半夜，运维人员把死掉的 redis-master 修好了，重新启动它：
Bash
docker start redis-master
你去查一下它现在的身份：
Bash
docker exec -it redis-master redis-cli info replication
结果： 它的 role 变成了 slave！它发现时代变了，只能乖乖给新当选的大哥做小弟。这就是哨兵极其强悍的故障自动转移能力！
学习总结
恭喜你！你刚刚亲手在本地电脑上完成了一次真实的阿里/腾讯级高可用灾难恢复演练。
你向系统中引入了独立于数据之外的第三方监控者（Sentinel）。它完美诠释了分布式系统中的“共识机制”和“自动化运维”理念。把刚才你在日志里看到的 sdown -> odown -> switch-master 流程刻在脑子里，这就是你面对面试官时最硬核的底气！
至此，我们的系统已经实现了“读写分离”和“永不宕机（高可用）”。
但是，随着双十一大促的到来，系统的商品数据达到了恐怖的 1TB。单台 Redis 最大内存才 64GB，哪怕你有 100 个小弟，每个小弟也只能存 64GB 的相同数据，根本装不下 1TB 的海量数据！
这就逼迫我们走向分布式缓存的最巅峰形态。
去见识真正能够无限横向扩容内存空间的终极杀器——“12. 分布式缓存 - 分片集群 (Sharding Cluster) 架构与分片原理”
