Redis—听说你速度跟甲斗一样快？——哨兵_若没有足够数量的 sentinel 同意 master 已经下线(1)

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Linux运维全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上运维知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注运维）

正文

• 如果发现对方在 指定时间( down-after-milliseconds项 )内未回应,则暂时认为对方已挂(主观宕机: sdown)
• 若“哨兵群“中的多数 sentinel,都报告某一master没响应,系统才认为该master”彻底死
  亡”(客观上的真正down机: odown),通过一定的 vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置
  

#主观宕机（SDOWN）
	即单个sentinel认为某个服务下线（有可能是接收不到订阅，网络不通等）
	主观下线就是说如果服务器在down-after-milliseconds给定的毫秒数之内，没有返回Sentinel 发送的 PING 命令的回复，或者返回一个错误，那么 Sentinel 将这个服务器标记为主观下线（SDOWN）

#客观宕机（ODOWN）
	多个sentinel实例对同一台服务器做出SDOWN判断，并且通过SENTINEL is-master-down-by-addr 命令互相交流之后，得出的服务器下线判断，然后开启failover。
	客观下线就是说只有在足够数量（quorum）的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（ODOWN），当sentinel监视的某个服务主观下线后，sentinel会询问其它监视该服务的sentinel，看它们是否也认为该服务主观下线，之后再进行故障迁移。
	sentinel通过发送 SENTINEL is-master-down-by-addr ip port current_epoch runid，（ip：主观下线的服务id，port：主观下线的服务端口，current_epoch：sentinel的纪元，runid：*表示检测服务下线状态，如果是sentinel 运行id，表示用来选举领头sentinel）来询问其它sentinel是否同意服务下线。
	一个sentinel接收另一个sentinel发来的is-master-down-by-addr后，提取参数，根据ip和端口，检测该服务时候在该sentinel主观下线，并且回复is-master-down-by-addr，回复包含三个参数：down_state（1表示已下线，0表示未下线），leader_runid（领头sentinal id），leader_epoch（领头sentinel纪元）。sentinel接收到回复后，根据配置设置的下线最小数量，达到这个值，既认为该服务客观下线。客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商， 所有从服务器或者其他 Sentinel 永远不会达到客观下线条件。只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。

1.sentinel 工作过程

1.每个sentinel向master、slave以及其他sentinel发送一个ping（1s一次）

2.每个sentinel向master的pub/sub频道道__sentinel__收发hello（包含sentinel ip:port及配置版本信息，所有sentinel通过这种方式达成共识）消息（两秒一次）

3.如果一个实例距离最后一次有效回复ping命令的时间超过down-after-milliseconds ，则这个实例会被Sentinel标记为主观下线

4.当有足够数量的sentinel（大于等于quorum）在指定的时间范围内确认master的确进入了主观下线状态，则master会被标记为客观下线

5.每个Sentinel 向所有Master，Slave发送 INFO 命令（正常十秒一次，标记客观下线后一秒一次）

6.若没有足够数量的Sentinel同意Master已经下线，或者若Master重新向Sentinel 的PING命令返回有效回复，Master的主观下线状态就会被移除
7.进行故障切换

8.维护sentinel配置版本及持久化sentinel节点及集群主从关系等信息到sentinel.conf

9.向外部客户端提供有效的redis-master连接信息（在故障切换后会更新）

2.leader选举

只能有一个sentinel能指挥完成整个集群的failover，所以当master客观下线时，需要进行sentinel leader选举
1.所有的sentinel都有公平被选举成领头的资格（前提未配置sentinel can-failover mymasterno，默认是yes）

2.所有的sentinel都有且只有一次将某个sentinel选举成领头的机会（在一轮选举中），一旦选举某个sentinel为领头，不能更改

3.sentinel设置领头sentinel规则是先到先得，一旦当前sentinel设置了领头sentinel，以后要求设置sentinel为领头请求都会被拒绝

4.每个发现服务客观下线的sentinel，都会要求其它sentinel将自己设置成领头

5.当一个sentinel（源sentinel）向另一个sentinel（目sentinel）发送is-master-down-by-addr ip port current_epoch runid命令的时候，runid参数不是*，而是sentinel运行id，就表示源sentinel要求目标sentinel选举其为领头

6.源sentinel会检查目标sentinel对其要求设置成领头的回复，如果回复的leader_runid和leader_epoch为源sentinel，表示目标sentinel同意将源sentinel设置成领头

7.如果某个sentinel被半数以上的sentinel设置成领头，那么该sentinel既为领头。

8.如果在限定时间内，没有选举出领头sentinel，暂定一段时间，再选举。

#注意事项：
1）redis集群需要开启外部网络访问，生产不能只侦听环回地址（伪集群测试无所谓了）
2）sentinel节点数量推荐是>=3个的奇数，quorum生效的前提是>=ceil(sentinel节点数量/2)
3）新增sentinel节点时请勿拷贝其它包含动态生成配置的sentinel配置文件

3.节点之间如何发现

我们发现sentinel配置文件里只配置了master的地址信息（host和port），并没有配置从节点以及其他哨兵节点的信息，但是我们在哨兵节点和主节点客户端通过info replication和info sentinel命令却能够发现它们，这是由哨兵的自动发现机制实现的

• 数据节点

一般情况下，哨兵节点每隔10秒（failover时每隔1秒）向主从节点发送info命令，以此获取主从节点的信息

首次执行时只知道给出的主节点信息，通过对主节点执行info命令就可以获取其从节点列表，如此周期执行，就可以不断发现新的节点

1.如果INFO命令目标是从节点：哨兵从返回信息中获取从节点所属的最新主节点ip和port，如果与历史记录不一致，则执行更新；获取从节点的优先级、复制偏移量以及与主节点的链接状态并更新。

2.如果INFO命令目标是主节点：哨兵从返回信息中获取主节点的从机列表，如果从节点是新增的，则将其加入监控列表。

3.无论目标是主节点还是从节点，都会记录其runId。

4.如果节点的角色发生变化，哨兵会记录节点新的角色及上报时间。若此时哨兵运行在TILT模式下，则什么都不做。否则，会执行主从切换相关的逻辑，我们后面再细说

• 哨兵节点

为了相互检查可用性及信息交互，哨兵之间是一直保持连接的，但是我们并没有配置告知它们彼此的存在，它们之间是怎么发现对方并交互的呢？

我们知道哨兵通过INFO命令发现了主节点及从节点的地址信息，而redis提供了一种发布订阅的消息通信模式，PUB/SUB。

哨兵们就是通过这一个约好的通道发布/订阅hello信息进行通信

每隔2秒，每个哨兵会通过它所监控的主节点、从节点向__sentinel__:hello通道发布一条hello消息。
每个哨兵会通过它所监控的主节点、从节点订阅__sentinel__:hello通道的消息，以此接收其他哨兵发布的信息

每个哨兵都会维护其监控的主节点信息，如果它接收到其他哨兵消息后，发现自己维护的信息已经过时，则立即执行更行过程。

如果哨兵接受到的信息没有在已有的监控列表中，就意味着发现了一个新的哨兵实例，此时会创建一个新的哨兵实例加入监控列表。在处理新增哨兵实例时，如果它与已存在的哨兵实例runId或者ip、port一致，将只保存最新的实例信息

哨兵部署

1.相关命令

redis-cli -h <IP> -p <PORT> info sentinel 
# 查看sentinel的整体信息

redis-cli -h <IP> -p <PORT> sentinel masters 
# 查看sentinel监控的所有redis-master信息

redis-cli -h <IP> -p <PORT> sentinel slaves testmaster 
# 查看sentinel监控的testmaster集群中redis-slave信息

redis-cli -h <IP> -p <PORT> sentinel get-master-addr-by-name testmaster 
# 获取testmaster组中的master ip和端口

redis-cli -h <IP> -p <PORT> sentinel reset pattern 
# 重置所有名字和给定模式pattern 相匹配的主服务器。pattern 参数是一个Glob 风格的模式

redis-cli -h <IP> -p 26379sentinel failover testmaster 
# 强制对testmaster进行failover

redis-cli -h <IP> -p <PORT> sentinel monitor <NAME> <IP> <PORT> <QUORUM> 
# 动态新增sentinel监控的redis集群

redis-cli -h <IP> -p <PORT> sentinel remove <NAME> 
# 动态删除sentinel监控的redis集群

redis-cli -h <IP> -p <PORT> sentinel <NAME> <OPTION> <VALUE> 
# 动态新增sentinel监控集群的配置，类似redis的CONFIG SET命令

2.配置字段说明

sentinel monitor mymaster 192.168.149.128 6379 2
#当前Sentinel节点监控 192.168.149.128 6379 这个主节点
#2代表判断主节点失败至少需要2个Sentinel节点节点同意
#mymaster是redis监控主节点的别名

sentinel down-after-milliseconds mymaster 10000
#每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过10000毫秒且没有回复，则判定不可达

sentinel parallel-syncs mymaster 1
#当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起同步操作，限制每次向新的主节点发起同步操作的从节点个数为1

sentinel failover-timeout mymaster 30000
#故障转移超时时间为30000毫秒

sentinel auth-pass 
#如果Sentinel监控的主节点配置了密码，可以通过sentinel auth-pass配置通过添加主节点的密码，防止Sentinel节点无法对主节点进行监控
#例如：sentinel auth-pass mymaster 88888888

sentinel notification-script
#在故障转移期间，当一些警告级别的Sentinel事件发生（指重要事件，如主观下线，客观下线等）时，会触发对应路径的脚本，想脚本发送相应的事件参数
#例如：sentinel notification-script mymaster /var/redis/notify.sh

sentinel client-reconfig-script
#在故障转移结束后，触发应对路径的脚本，并向脚本发送故障转移结果的参数。
#例如：sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

• master配置

[root@master ~]# vim /etc/redis/redis-sentinel.conf
bind0.0.0.0
port 26379
pidfile /var/redis/sentinel.pid
dir /var/lib/redis


为了做好运维面试路上的助攻手，特整理了上百道 **【运维技术栈面试题集锦】** ，让你面试不慌心不跳，高薪offer怀里抱！

这次整理的面试题，**小到shell、MySQL，大到K8s等云原生技术栈，不仅适合运维新人入行面试需要，还适用于想提升进阶跳槽加薪的运维朋友。**

![](https://img-blog.csdnimg.cn/img_convert/2a3243e195ec51c3071899d4b1885638.png)

本份面试集锦涵盖了

*   **174 道运维工程师面试题**
*   **128道k8s面试题**
*   **108道shell脚本面试题**
*   **200道Linux面试题**
*   **51道docker面试题**
*   **35道Jenkis面试题**
*   **78道MongoDB面试题**
*   **17道ansible面试题**
*   **60道dubbo面试题**
*   **53道kafka面试**
*   **18道mysql面试题**
*   **40道nginx面试题**
*   **77道redis面试题**
*   **28道zookeeper**

**总计 1000+ 道面试题， 内容 又全含金量又高**

*   **174道运维工程师面试题**

> 1、什么是运维?

> 2、在工作中，运维人员经常需要跟运营人员打交道，请问运营人员是做什么工作的?

> 3、现在给你三百台服务器，你怎么对他们进行管理?

> 4、简述raid0 raid1raid5二种工作模式的工作原理及特点

> 5、LVS、Nginx、HAproxy有什么区别?工作中你怎么选择?

> 6、Squid、Varinsh和Nginx有什么区别，工作中你怎么选择?

> 7、Tomcat和Resin有什么区别，工作中你怎么选择?

> 8、什么是中间件?什么是jdk?

> 9、讲述一下Tomcat8005、8009、8080三个端口的含义？

> 10、什么叫CDN?

> 11、什么叫网站灰度发布?

> 12、简述DNS进行域名解析的过程?

> 13、RabbitMQ是什么东西?

> 14、讲一下Keepalived的工作原理?

> 15、讲述一下LVS三种模式的工作过程?

> 16、mysql的innodb如何定位锁问题，mysql如何减少主从复制延迟?

> 17、如何重置mysql root密码?

**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注运维）**
![img](https://img-blog.csdnimg.cn/img_convert/2ca043a8ac8dc7086339e5d27f00b546.jpeg)

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
nodb如何定位锁问题，mysql如何减少主从复制延迟?

> 17、如何重置mysql root密码?

**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注运维）**
[外链图片转存中...(img-MsyvAEVa-1713399098273)]

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**