Redis哨兵模式是什么意思

约 8 分钟读完 8 阅
文章导读
「Redis哨兵模式」通常指用一组 Sentinel 进程看住一套主从 Redis：定期检查主节点和从节点是否存活，主节点失联时按约定流程把某个从节点提升为主节点，并通知客户端新地址。它解决的是主从复制本身不会自动切换的问题，不是给 Redis 增加分片或扩容能力。判断一套部署算不算哨兵模式，可以直接看进程、端口和配置项：Sentinel 进程一般单独启动，配置文件里能看到 sentinel mo
📋 目录
  1. 壹 Redis哨兵模式到底指什么
  2. 贰 Redis哨兵模式和哪几个说法容易混
  3. 叁 什么情况其实用不上Redis哨兵模式
  4. 肆 Redis哨兵模式：三个动作确认你真的搞懂了
A A

「Redis哨兵模式」通常指用一组 Sentinel 进程看住一套主从 Redis：定期检查主节点和从节点是否存活，主节点失联时按约定流程把某个从节点提升为主节点，并通知客户端新地址。它解决的是主从复制本身不会自动切换的问题，不是给 Redis 增加分片或扩容能力。判断一套部署算不算哨兵模式，可以直接看进程、端口和配置项：Sentinel 进程一般单独启动，配置文件里能看到 sentinel monitor、sentinel down-after-milliseconds、sentinel failover-timeout 这类行；连接方式通常是客户端连 Sentinel 端口拿主节点地址，而不是把主节点 IP 写死在应用配置里。

Redis 哨兵模式等于主从复制加上 Sentinel 的监控、主观/客观下线判断和自动故障转移。适用场景是单主写入、能接受秒级到分钟级切换中断、客户端支持从 Sentinel 获取主节点地址的部署。操作上先确认 Sentinel 进程数量和 sentinel monitor 配置一致，再确认客户端走 Sentinel 而不是直连主节点。验证可以用 redis-cli -p 26379 SENTINEL get-master-addr-by-name 看返回地址是否随切换变化。风险边界：哨兵不解决数据分片和写扩散，异步复制下切换可能丢最后一段写入，需结合业务确认取舍。

Redis哨兵模式到底指什么

用一句话拆开：Redis 主从复制负责把主节点数据同步给从节点，Sentinel 负责盯着这些节点并在主节点不可用时发起选举和切换。Sentinel 本身是一个特殊模式的 Redis 进程，默认端口常为 26379，可以用 redis-sentinel sentinel.conf 或 redis-server sentinel.conf --sentinel 启动。它不是 Redis 的存储节点，不保存业务数据。

要核对一套部署是否真在跑哨兵，可以先执行下面这组只读检查，在任意一台能连到 Sentinel 的机器上跑：

# 看哨兵进程和启动参数
ps -ef | grep -i sentinel | grep -v grep

# 问哨兵当前认为的主节点是谁
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster

# 看这个主节点下挂了哪些从节点和其他哨兵
redis-cli -p 26379 SENTINEL slaves mymaster
redis-cli -p 26379 SENTINEL sentinels mymaster

# 看哨兵自己的运行状态
redis-cli -p 26379 INFO sentinel

替换项只有两个：26379 换成实际 Sentinel 端口，mymaster 换成 sentinel monitor 里配置的集群名。INFO sentinel 的返回里能看到 sentinel_masters、master0:name=...、status=ok 这类字段，status 不是 ok 就要先查网络和哨兵之间的通信，而不是急着调应用。失败排查通常看 Sentinel 日志，日志位置由配置文件里的 logfile 决定，没配则输出到标准输出，systemd 托管时可以先用 journalctl -u 服务名 找。

Redis哨兵模式是什么意思

Redis哨兵模式和哪几个说法容易混

这几个词经常被混着用，但成因和判断条件不同：

  • 主从复制：只做数据同步，不自动切换。判断条件：配置里只有 replicaof，没有 Sentinel 进程，主节点宕机后客户端写入直接失败，INFO replication 里角色不会自己变。
  • Redis Cluster：分片加故障转移，数据按槽分散在多个主节点。判断条件：节点用 cluster-enabled yes 启动，CLUSTER INFO 能看到 cluster_state:ok，客户端需要按槽路由。看到槽信息就说明不是哨兵模式。
  • 客户端自动重连/连接池重试：只解决连接断开后的重连，不解决主节点地址变化。判断条件：应用配置里写死单个 IP，日志出现主节点变了但应用还连旧地址，或重试后仍然写失败。
  • 代理层做的主从切换：由中间件探测后端并转发，Redis 侧可能仍是普通主从。判断条件：应用连的是代理地址，而不是 Sentinel 端口，Sentinel 查询结果和代理实际指向可能不同步。

一眼分辨的简单办法：能执行 SENTINEL get-master-addr-by-name 并返回地址，说明有哨兵参与；如果返回的是 cluster_enabled:1 或者需要按 key 算槽，就是 Cluster；两者都不是，多半只是主从加应用侧重试。

什么情况其实用不上Redis哨兵模式

哨兵不是默认选项，下面这些情况可以先不引入：

Redis哨兵模式是什么意思
  • 数据量小、可接受短暂不可写：单机 Redis 加持久化和备份就够，引入哨兵反而多出三份进程和一套切换逻辑要维护。判断依据是先看业务能否接受故障时人工介入恢复。
  • 已经在用 Redis Cluster：Cluster 自身有故障转移，再叠一套 Sentinel 没有意义，还容易让客户端连接配置混乱。判断依据是 cluster-enabled 是否打开。
  • 客户端或框架不支持 Sentinel 地址发现：需要确认所用客户端版本和连接配置里是否有 Sentinel 相关参数。如果只能配单机地址，强行上哨兵会出现切换后应用仍连旧主节点。可以先查客户端配置项是否支持 sentinel 节点列表，不支持就考虑代理层或升级客户端。
  • 团队没有监控和演练条件：哨兵切换后需要有人确认新主节点、旧主节点恢复后的角色，以及是否有数据差异。没有日志采集和告警时，切换可能悄悄发生却没人知道。
  • 权限或成本受限：哨兵至少建议部署三个实例做多数派判断，机器或容器资源不足时，单哨兵无法形成可靠仲裁，这种环境更适合先做备份和人工切换预案。

替代做法要写清楚边界：主从加定期备份适合能容忍停机恢复的场景；Cluster 适合需要水平扩展写入的场景；代理层适合客户端改造困难但愿意多维护一个组件的场景。三者都不是哨兵的“升级版”，只是取舍不同。

Redis哨兵模式：三个动作确认你真的搞懂了

光看概念不够，做下面三个动作能确认理解是否落地。

  1. 查一次主节点地址并记录：执行 redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster。预期结果是返回一组 IP 和端口，和当前实际主节点一致。如果返回空或报错，说明集群名写错、端口不对或哨兵没起来；如果返回地址和应用配置里的地址不一致，说明应用没走哨兵发现。
  2. 看一次哨兵视图：执行 redis-cli -p 26379 SENTINEL masters 和 SENTINEL sentinels mymaster。预期结果是主节点状态为 ok、能看到配置的从节点数量和其余哨兵地址。数量少于配置值，说明有节点掉线或网络不通；num-other-sentinels 为 0 说明只有一个哨兵，多数派判断不成立。
  3. 在测试环境做一次受控切换：停掉测试主节点的 Redis 进程，观察日志和 SENTINEL get-master-addr-by-name 的返回是否在 down-after-milliseconds 加切换时间后变化。预期结果是地址切到某个从节点，应用重连后恢复写入。如果长时间不切换，先查哨兵之间是否互通、quorum 是否配置合理；如果切换了但应用仍写旧地址，问题在客户端发现逻辑；如果切换后出现数据缺失，是异步复制的正常风险，需要在业务侧确认能否接受。

版本、端口默认值和具体命令返回字段可能随 Redis 版本变化，实际以本机 redis-cli INFO 和所用版本的配置示例为准，不同环境先在小范围确认再推广。