redis哨兵配置中sentinel monitor的ip不能写127.0.0.1，因为该地址在容器内指向自身而非主节点；应使用docker内部服务名（如redis-master）或宿主机可路由的真实ip，确保哨兵能跨容器建立tcp连接。
Redis 哨兵配置文件里 sentinel monitor 的 IP 为什么不能写 127.0.0.1
因为哨兵进程运行在 Docker 容器内，127.0.0.1 指向的是容器自身，不是宿主机或其它容器。如果主节点（master）在另一个容器里，哨兵根本连不上。
实操建议：
- 用 Docker 网络的内部服务名，比如
redis-master（对应docker-compose.yml中定义的 service name），这是最稳妥的方式 - 避免硬编码 IP；若必须用 IP，应是 Docker bridge 网络分配给目标容器的 IP（可通过
docker network inspect查看，但不推荐） -
sentinel monitor mymaster redis-master 6379 2中的redis-master必须与docker-compose.yml里 service 名完全一致（区分大小写）
Sublime Text 怎么实时验证 sentinel.conf 语法是否合法
Sublime Text 本身不校验 Redis 配置语法，但可以快速触发验证——关键在于把编辑、构建、反馈链路串起来。
实操建议：
- 在 Sublime Text 中配置自定义 Build System：新建
Tools → Build System → New Build System，填入以下内容（保存为redis-sentinel-validate.sublime-build）：
{
"shell_cmd": "redis-server --test-mode --sentinel $file 2>&1 || echo '✅ config OK'",
"file_regex": ".*ERR.*",
"selector": "source.redis-conf"
}
- 确保系统已安装 Redis CLI 工具（非仅客户端），否则
redis-server --test-mode会报错command not found - 在
sentinel.conf文件中右键 →Build With → redis-sentinel-validate，错误会直接高亮显示在 Sublime 底部状态栏
Docker Compose 启动后哨兵日志里反复出现 +sdown master mymaster
这说明哨兵无法与主节点建立 TCP 连接，不是配置语法问题，而是网络或端口暴露问题。
实操建议：
- 确认主节点 Redis 容器监听的是
0.0.0.0:6379，而非127.0.0.1:6379（检查redis.conf中bind配置） - 确认
docker-compose.yml中主节点 service 的ports:是用于调试的映射（如- "6379:6379"），但哨兵间通信依赖的是内部网络，**不需要**为哨兵容器暴露26379端口给宿主机 - 检查哨兵容器是否和主节点在同一自定义网络（
networks:必须显式声明并共用同一网络名），默认bridge网络下 service name 不生效
为什么改完 sentinel.conf 重启容器后哨兵仍读旧配置
Docker 容器启动时若未挂载配置文件，会使用镜像内置的默认 sentinel.conf；即使你本地编辑了文件，容器里压根没加载它。
实操建议：
- 必须通过
volumes:显式挂载，例如：./conf/sentinel1.conf:/usr/local/etc/redis/sentinel.conf - 注意路径权限：Docker 内 Redis 进程以
redis用户运行（UID 999），宿主机挂载文件需确保该用户有读取权限（chmod 644即可） - 别依赖
command:启动参数覆盖配置路径，哨兵模式下redis-server /path/to.conf --sentinel无效；必须让redis-server启动时自动识别--sentinel标志，通常靠入口脚本或镜像约定（官方镜像要求 conf 文件名含sentinel或显式指定）
哨兵集群真正难调的从来不是单个配置项，而是容器网络命名空间、Redis 进程用户权限、以及配置加载时机三者叠加后的静默失败——尤其当 redis-server 启动成功但没读你的 sentinel.conf 时，日志里几乎不报错。
