Redis Sentinel是官方提供的高可用解决方案，它通过独立进程监控Redis主从节点，并在主节点故障时自动完成故障转移。很多人只关注Redis数据节点本身的密码设置，却忽略了Sentinel节点同样暴露在网络上，任何一个知道Sentinel端口的人都可以通过命令强制触发主从切换，甚至让Sentinel误判节点状态。因此，为Sentinel配置密码认证并不是可选项，而是生产环境的基本要求。
Sentinel密码认证的作用与配置前提
Sentinel节点之间需要通过命令互相通信，Sentinel也会向Redis主从节点发送INFO、PING等命令。如果主节点设置了requirepass，那么Sentinel必须知道这个密码才能正常监控，否则Sentinel会把主节点标记为主观下线，进而触发不必要的故障转移。同理，如果Sentinel节点本身没有设置密码，任何客户端都可以连接Sentinel执行SENTINEL failover之类的危险命令。
配置Sentinel密码时有两个关键参数：一个是Sentinel自身的requirepass，用于限制客户端对Sentinel的访问；另一个是masterauth，用于Sentinel连接Redis主从节点时使用的密码。很多配置文件里masterauth容易被遗漏，导致故障转移后Sentinel无法和新主节点建立认证连接，集群状态异常。
另外需要注意，Redis主节点、从节点和Sentinel节点三者的密码必须保持一致，否则会出现主从复制中断或者Sentinel无法同步信息的情况。在Redis Stack环境中，由于包含了模块和额外的配置管理界面，密码设置的位置基本不变，但通过Redis Stack的配置面板修改时需要确保配置被正确持久化到sentinel.conf文件。
配置Sentinel节点和主从节点密码的完整步骤
首先修改Redis主节点和从节点的配置文件，添加requirepass和masterauth。主节点需要设置requirepass，从节点除了requirepass外还要设置masterauth指向主节点密码。下面是一个主节点配置示例：
# redis-master.conf port 6379 requirepass "Str0ngP@ssw0rd" masterauth "Str0ngP@ssw0rd"
从节点配置文件类似，但masterauth必须与主节点密码一致，否则复制连接会被拒绝。接着为Sentinel节点创建独立的配置文件sentinel.conf，内容如下：
# sentinel.conf port 26379 sentinel monitor mymaster 127.0.0.1 6379 2 sentinel auth-pass mymaster Str0ngP@ssw0rd sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 10000 requirepass "SentinelP@ssw0rd"
这里sentinel auth-pass就是Sentinel连接Redis数据节点时使用的密码，而requirepass是保护Sentinel自身端口的密码。两个密码可以不同，但主从节点自身的requirepass和masterauth必须保持一致。启动Sentinel时使用redis-sentinel /path/to/sentinel.conf命令，或者在Redis Stack安装包中执行redis-stack-sentinel并指定配置文件。
配置完成后，可以通过redis-cli连接Sentinel验证。连接时如果不带密码，执行任何命令都会返回NOAUTH Authentication required。正确连接方式为redis-cli -p 26379 -a SentinelP@ssw0rd，然后执行SENTINEL master mymaster查看主节点信息。如果返回的flags包含master，说明Sentinel认证和监控均正常。
Redis Stack环境下Sentinel密码同步的注意事项
Redis Stack集成了Redis、RedisJSON、RediSearch等模块，部署Sentinel时通常使用同一套二进制文件。在Redis Stack中，Sentinel的配置仍然通过sentinel.conf文件管理，但部分云平台或容器镜像可能提供了环境变量注入方式。无论哪种方式，核心参数不变：requirepass用于Sentinel自身认证，sentinel auth-pass用于连接数据节点。
一个常见误区是只通过CONFIG SET命令动态修改密码，而没有写入配置文件。虽然CONFIG SET requirepass会立即生效，但Sentinel重启后就会丢失。正确的做法是同时修改sentinel.conf文件，并执行SENTINEL SET mymaster auth-pass Str0ngP@ssw0rd让运行时配置与文件保持一致。在Redis Stack的Web管理界面中修改密码时，也要确认底层配置文件是否被正确更新，否则重启后会出现配置回退。
此外，如果使用Docker部署Redis Stack和Sentinel，需要把配置文件挂载到容器内，并且注意容器启动脚本中密码参数的位置。例如通过-e REDIS_PASSWORD=xxx设置的环境变量可能只影响Redis数据节点，而不影响Sentinel进程，此时Sentinel仍然没有密码保护。建议显式提供一份完整的sentinel.conf并挂载到/etc/redis/sentinel.conf路径。
客户端连接与故障转移验证
客户端连接Sentinel获取主节点地址时，Sentinel不会要求客户端提供数据节点的密码，但客户端在连接返回的主节点地址后，仍然需要提供requirepass对应的密码。一些高级客户端（如Lettuce、Jedis、redis-py）支持在Sentinel模式下同时配置Sentinel密码和节点密码，避免认证失败。
故障转移过程中，Sentinel会提升一个从节点为新主节点，原主节点恢复后自动降级为从节点。此时新主节点必须已经配置了requirepass和masterauth，否则Sentinel无法向新主节点发送SLAVEOF命令，也无法完成复制拓扑更新。如果新主节点密码缺失，Sentinel日志中会出现NOAUTH Authentication required错误，并且故障转移流程会卡住。
可以通过手动触发故障转移来验证密码配置是否完整。在Sentinel连接中执行SENTINEL failover mymaster，观察日志和节点角色变化。如果一切正常，说明Sentinel密码、主从节点密码以及复制认证都配置正确。这个过程还能暴露出密码不一致、特殊字符转义等问题，建议在生产变更前先在测试环境完整演练一遍。
常见错误与排查思路
第一种错误是主节点设置了密码，但Sentinel没有配置sentinel auth-pass。这会导致Sentinel无法执行INFO命令，从而把主节点标记为sdown状态。排查时可以使用redis-cli -p 26379 -a SentinelP@ssw0rd sentinel masters查看每个主节点的flags，如果出现s_down且主节点实际存活，基本就是认证问题。
第二种错误是从节点的masterauth与主节点的requirepass不一致。主从复制建立时，从节点会使用masterauth向主节点认证，密码错误会导致复制中断。在从节点日志中会看到Master does not understand REPLCONF listening-port: -NOAUTH Authentication required类似的提示。解决办法是统一所有节点的requirepass和masterauth值。
第三种错误是密码包含特殊字符导致配置文件解析异常。例如密码中含有#、空格或双引号时，如果没有正确加引号转义，可能只生效部分密码。建议使用强随机密码并放在引号内，避免使用$、!等shell敏感字符。如果使用redis-cli -a连接时密码包含特殊字符，可以用--no-auth-warning参数并确保密码正确转义。
最后，如果Sentinel节点之间的通信也需要加密或认证，目前Redis官方没有提供Sentinel间的TLS认证，但可以借助网络层ACL或防火墙限制Sentinel端口只允许可信来源访问。生产环境建议将Sentinel端口绑定到内网IP，避免暴露到公网。
Redis Sentinel密码认证Redis Stack修改时间：2026-08-29 06:36:50