当前位置：首页 > 问答 > 正文

Redis哨兵配置文件怎么写才对，使用中有哪些坑和注意点

革姣丽
问答
2025-12-28 15:00:41
1

Redis哨兵配置文件怎么写才对

Redis哨兵的配置文件通常命名为 sentinel.conf，要让哨兵正常工作，以下几个配置项是核心且必须正确设置的，配置的编写思路是：先定义你要监控的主节点,然后设置一些全局的哨兵参数。

最关键的配置是指定哨兵要监控的主服务器,格式如下：

sentinel monitor <主节点名称> <主节点IP> <主节点端口> <法定票数>

<主节点名称>：你自己给主节点起个名字，my-master，注意,这个名称在同一个哨兵集群中必须一致。
<主节点IP> 和 <主节点端口>：就是当前主Redis服务器的地址。
<法定票数>：这个数字非常重要，它表示判断主节点“客观下线”需要至少几个哨兵同意，这个值通常设置为 哨兵总数 / 2 + 1，你有3个哨兵，那么法定票数就设为2,这样能避免单个哨兵网络抖动造成的误判。

设置主节点失联多久后才会被判断为“主观下线”,格式如下：

sentinel down-after-milliseconds <主节点名称> <毫秒数>

<毫秒数>：默认是30000毫秒（30秒），如果哨兵在这个时间内没有收到主节点的有效回复（包括PING命令的回复或信息同步），它就认为这个主节点“主观下线”了，你可以根据网络状况调整这个值，网络差就设长一点，要求高可用就设短一点,但太短容易误判。

配置故障转移时，从节点同步新主节点的超时时间,格式如下：

sentinel failover-timeout <主节点名称> <毫秒数>

<毫秒数>：默认180000毫秒（3分钟），这个参数有多重含义：1）一次故障转移的总超时时间；2）同一个主节点再次故障转移的冷却时间，如果故障转移超时，即使失败了，哨兵也会等这么久才尝试下一次转移,调大这个值可以避免在集群不稳定时频繁触发转移。

配置故障转移后，每次同时进行数据同步的从节点数量,格式如下：

sentinel parallel-syncs <主节点名称> <数量>

<数量>：默认是1，当新主节点被选举出来，剩下的从节点需要向它发起数据同步，这个配置决定了允许同时进行同步的从节点个数，设置为1是最稳妥的，因为全量同步时主节点需要生成RDB文件并传输，IO压力大，如果从节点很多且希望快速恢复冗余，可以适当调大,但会增加主节点负载。

一个最简化的、针对主节点 mymaster（IP: 127.0.0.1，端口6379）的三哨兵集群配置示例（其中一个哨兵的配置）可能看起来像这样：

port 26379 // 哨兵自己服务的端口
daemonize yes // 以守护进程运行
logfile "/var/log/redis/sentinel.log" // 日志文件路径
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

使用中的坑和注意点

Redis哨兵配置文件怎么写才对，使用中有哪些坑和注意点

哨兵节点数量必须是奇数：这是分布式系统共识算法（Raft）的要求，奇数个节点（如3个或5个）可以避免在判断主节点下线时出现票数相等的情况，从而无法做出决策（脑裂），2个哨兵法定票数只能设为2，任何一个哨兵挂掉，整个哨兵集群就瘫痪了，无法完成故障转移，而3个哨兵法定票数为2,可以容忍1个哨兵失败。
哨兵配置会被动态重写：这是一个非常大的坑，当哨兵通过选举完成一次故障转移后，它会自动修改自己的配置文件，将监控的主节点地址更新为新的主节点IP和端口，这是正常行为。绝对不要手动去修改运行中的哨兵配置文件，你的修改很可能在下次故障转移后被覆盖，如果需要修改配置（比如调整超时时间），最好先停掉哨兵，修改配置,再重启。
客户端实现的复杂性：故障转移对客户端不是完全透明的，一个支持哨兵的客户端，其工作逻辑应该是：首先连接哨兵集群，从一个哨兵那里查询当前主节点的地址，然后连接到主节点，客户端需要订阅哨兵的信道，当收到主节点切换的消息时，需要及时断开旧连接，与新主节点建立新连接，如果客户端实现得不好（比如没有监听消息或重连逻辑有问题），即使哨兵成功切换，客户端也会一直连着已经宕机的旧主,导致业务中断。
网络分区（脑裂）风险：虽然哨兵和奇数个节点的设计旨在减少脑裂，但在复杂的网络故障下仍有可能发生，主节点和它的从节点被隔离在两个网络区域，如果少数派区域（比如只有一个从节点）的哨兵认为主节点下线，并把这个从节点提升为主节点，那么就会出现两个“主节点”，都接受写请求，导致数据不一致，解决这个问题需要谨慎设置 min-slaves-to-write（主节点至少要有N个从节点连接才允许写）和 min-slaves-max-lag（从节点数据复制延迟不能超过M秒）这两个主节点配置，在网络分区时让原来的主节点停止写入,减少数据损失。
确保哨兵和Redis节点时钟同步：哨兵系统依赖于超时判断，如果哨兵节点和Redis节点之间的时钟差异很大，可能会导致误判,务必使用NTP服务确保所有服务器的时间基本一致。
权限和安全：如果Redis配置了密码，必须在哨兵配置中为每个监控的主节点设置认证密码，格式是 sentinel auth-pass <主节点名称> <密码>，主从节点的密码必须一致，考虑使用防火墙规则，只允许可信的IP地址访问哨兵端口（默认26379）和Redis端口,避免被恶意攻击。
资源分离：在生产环境中，尽量将哨兵进程部署在独立的服务器上，或者与Redis主从节点分开部署，避免哨兵进程和Redis进程争夺CPU、内存资源,尤其是在Redis持久化或故障转移等高负载场景下。
监控哨兵本身：哨兵是高可用的守护者，但它自己也可能出问题，一定要监控哨兵进程的状态，确保它们都在正常运行，可以通过哨兵提供的API命令（如 sentinel masters）来检查其健康状态。