Redis 哨兵节点之间相互自动发现机制（自动重写哨兵节点的配置文件）

 

Redis的哨兵机制中，若是是多哨兵模式，哨兵节点之间也是能够相互感知的，各类搜索以后出来的是千篇一概的一个基础配置文件，
在配置当前哨兵节点的配置文件中，并无配置其余哨兵节点的任何信息。
以下是一个哨兵节点的配置信息，能够看到，哨兵与哨兵之间没有任何配置，死活想不明白，哨兵之间是如何自动识别的。

#sentinel端口
port 26379
#工做路径，注意路径不要和主重复
dir "./"
# 守护进程模式
daemonize yes
#关闭保护模式
protected-mode no
# 指明日志文件名
logfile "./sentinel.log"
#哨兵监控的master，主从配置同样，这里只用输入redis主节点的ip/port和法定人数。
sentinel monitor mymaster 127.0.0.1 6379 2
# master或slave多长时间（默认30秒）不能使用后标记为s_down状态。
sentinel down-after-milliseconds mymaster 5000
#若sentinel在该配置值内未能完成failover操做（即故障时master/slave自动切换），则认为本次failover失败。
sentinel failover-timeout mymaster 18000
#设置master和slaves验证密码
sentinel auth-pass mymaster root

参考“http://www.javashuo.com/article/p-xtdpgzll-ed.html”中的说法

 

那么哨兵节点直接是如何自动发现的呢，或者说从哪里能够体现出来哨兵节点之间的自动发现呢？
既然会自动识别，所以就怀疑，哨兵节点启动以后，会将自动将这些信息记录到配置文件中去，试了一把，果不其然。

 

以下是在Redis主从复制的基础上，依次启用三个哨兵节点的后，sentinel.cnf的变化状况
能够发现，当启用了三个哨兵节点以后，sentinel.cnf配置文件会被自动重写，主要有一下几点，如截图从#Generated by CONFIG REWRITE开始
1，增长了一个sentinel myid （标识哨兵节点的惟一性）
2，自动追加哨兵节点自己的信息（这样哨兵节点之间就会相互自动发现），以及redis数据服务的slave的信息
3，自动移除主节点的密码
4，dir 的相对路径被修改成绝对路径

可见，Redis的哨兵不只是Redis自动故障转义，并且实现了哨兵节点本身的高可用。同时对于密码之类的信息，也是在哨兵节点初始化以后自动移除。

 

其实这个哨兵机制的拓扑图（来自于redis开发与运维），我的感受以下，各个哨兵节点之间应该是一个“图”的关系，任何两个哨兵节点都是互通的。

主节点自动故障转移的效果。