Redis哨兵状态怎么快速看一眼，顺便聊聊redis哨兵那些事儿

怎么快速看一眼哨兵状态？

你想知道哨兵是不是在正常工作，主从关系有没有问题，根本不用去翻那些又长又臭的日志文件，Redis哨兵自己就提供了几个非常简单的命令，让你像看仪表盘一样快速了解全局，你只需要用redis-cli工具连上任意一个哨兵节点的端口（默认是26379）,然后输入几个命令就行。

1. 最直观的一眼：info Sentinel 这是我最常用的命令，可以说是“一键体检”，你连上哨兵后，直接打info Sentinel，它会给你吐出来最核心的信息,你会看到类似这样的内容：

   # Sentinel
   sentinel_masters:1
   sentinel_tilt:0
   sentinel_running_scripts:0
   sentinel_scripts_queue_length:0
   sentinel_simulate_failure_flags:0
   master0:name=mymaster,status=ok,address=192.168.1.10:6379,slaves=2,sentinels=3

   这几行字信息量巨大：

   • sentinel_masters:1：告诉你这个哨兵集群目前只监控着一个主库（叫master0）。
   • master0:name=mymaster：这个主库的名字是mymaster，这是你在哨兵配置文件里给它起的“小名”。
   • status=ok：最关键的一行！ 如果这里是ok，谢天谢地，说明主库活着呢，一切正常，如果主库挂了，这里会显示fail之类的状态,那就要出大事了。
   • address=192.168.1.10:6379：当前被认定为主库的服务器IP和端口。
   • slaves=2：这个主库下面挂着2个从库。
   • sentinels=3：监控这个主库的哨兵进程总共有3个，这个数很重要，如果实际有3个哨兵进程，但这里只显示2个，说明有个哨兵可能失联了,得去查查。

2. 看看“兄弟们”都在不在：sentinel sentinels <master-name> 光自己觉得没问题不行，得看看监控同一个主库的其他哨兵兄弟是不是也这么认为，输入sentinel sentinels mymaster（把mymaster换成你的主库名），它会列出所有其他哨兵的详细信息，包括IP、端口、最后更新时间等，如果列表里的数量比你部署的少，那肯定有哨兵掉队了,网络或者进程可能出了问题。

3. 查查“小弟们”是否健康：sentinel slaves <master-name> 这个命令用来查看主库下的所有从库状态，它会列出每个从库的地址、复制状态（是已经和主库同步好了，还是在同步中）、延迟了多少数据等等，如果某个从库的flags里显示s_down（主观下线）或o_down（客观下线），或者复制延迟非常大，那这个从库就有问题,可能无法在主库挂掉时顶上去。

基本上，你日常巡检，连上哨兵，敲一个info Sentinel，半秒钟就能知道系统大体是否健康，如果有异常,再根据情况用后面两个命令细看。

第二部分：聊聊哨兵那些事儿

好了，快速看一眼的方法说完了，咱们来扯扯哨兵到底是干嘛的，以及它工作时那些有意思的“内心戏”。（根据Redis官方文档和社区普遍认知）

哨兵的核心任务：自动化的主从切换

你可以把Redis的主从复制架构想象成一个“大王带小弟”的模式，一开始，所有写请求都找大王（主库），小弟（从库）只负责读和备份，但问题是，万一大王突然驾崩了，整个系统不就只能读不能写,瘫痪了吗？

哨兵干的就是“内阁大臣”的活儿，它是一组独立的进程，不负责存数据，只负责瞪大了眼睛盯着大王和小弟们的死活，它的核心使命就一条：一旦发现大王（主库）挂了，立马从小弟（从库）中选出一个新的来继位，并且通知所有应用程序（客户端）以后要拜见新大王。

哨兵是怎么“看”的？心跳检测

哨兵们会定期（比如每秒一次）向所有主库和从库发送一个PING命令，如果某个实例在规定时间内没回复PONG，哨兵就会觉得“哎哟，这家伙可能不行了”，但一个哨兵觉得不行不算数，这叫做“主观下线”,万一只是网络抖了一下呢？

关键的“投票”机制：客观下线

这时候，哨兵的民主制度就发挥作用了，那个发现主库不行的哨兵，会去问其他哨兵：“嘿，哥们儿，你们觉得大王还活着吗？” 当足够多的哨兵（这个数量可以在配置文件里设置，比如超过一半）都报告说联系不上大王时，才会正式判定大王“客观下线”，这就避免了因为单个哨兵的网络问题而误判，导致不必要的“宫廷政变”。

选举新王：Raft协议与纪元

一旦大王被判定为客观下线，哨兵们就要开会选举一个新王，这个选举过程用的是Raft算法（一种分布式一致性算法），简单说就是每个哨兵都会先投自己一票，然后把票投给最先发起选举的哨兵，谁票多谁就成为“领头哨兵”。

这个领头哨兵的责任重大，它来负责从剩下的健康从库里，选一个数据最新的，把它提升为新的主库，然后命令其他从库去复制这个新主库,最后把新主库的地址通知给所有客户端。

这里有个很重要的概念叫“纪元”（epoch），你可以理解成“朝代编号”，每次主从切换，纪元号都会加一，客户端和哨兵都只认最新的纪元号，这样就能保证大家不会听信过时的消息,跑去拜见已经退位的老国王。

客户端怎么配合？

客户端要聪明，它不能死记硬背主库的地址，它需要先连接哨兵，问一句：“当前的主库地址是啥？”拿到地址后再去连接，当发生主从切换后，哨兵会发布通知，客户端监听到通知后，就会断开旧连接，重新向哨兵询问新主库地址并连接，这就是所谓的“智能客户端”。

哨兵的局限

哨兵虽然好用，但也不是万能的，它解决了高可用问题，但没解决数据容量的问题，如果你的数据量超级大，一个Redis实例根本存不下，那就得用Redis Cluster（集群）模式了,那个是另一套更复杂的玩法。

Redis哨兵就是一个自动化的故障转移系统，通过心跳、投票、选举这一套流程，确保Redis主从架构在主机宕机时能快速恢复服务，实现高可用，你平时用info Sentinel那一眼,看的其实就是这套流程最终呈现出来的结果状态。