Redis的哨兵机制或者心跳机制模式原理详解

落日映苍穹つ 2022-05-16 10:20 172阅读 0赞

转载自 [https://blog.csdn.net/yswKnight/article/details/78158540][https_blog.csdn.net_yswKnight_article_details_78158540]

## 一.什么是哨兵机制? ##

答：Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:  
       **监控(Monitoring)**: 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。  
       **提醒(Notification)**:当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

** 自动故障迁移(Automatic failover)**:当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

** ****哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程**,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。  
     ** **每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave**定时**发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).  
若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。  
     ** **虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)。  
      哨兵(sentinel) 的一些设计思路和zookeeper非常类似

![Center][]

## 二.哨兵模式的配置修改 ##

实现步骤:  
1.拷贝到etc目录  
   ** cp sentinel.conf  /usr/local/redis/etc**  
2.修改sentinel.conf配置文件  
**    sentinel monitor mymast  192.168.110.133 6379 1**  \#主节点 名称 IP 端口号 选举次数

\#配置主服务器的密码(如没设置密码，可以省略)    
   **sentinel auth-pass mymaster 123456  **  
3. 修改心跳检测 5000毫秒  
**    sentinel down-after-milliseconds mymaster 5000**  
4. 做多多少合格节点

**    sentinel parallel-syncs mymaster 2**  
5. 启动哨兵模式  
   **./redis-server /usr/local/redis/etc/sentinel.conf --sentinel &**  
6. 停止哨兵模式

注意：

1.当启动哨兵模式之后，如果你的master服务器宕机之后，哨兵自动会在从redis服务器里面 投票选举一个master主服务器出来；这个主服务器也可以进行**读写**操作！

2.如果之前宕机的主服务器已经修好，可以正式运行了。那么这个服务器只能进行**读**的操作，会自动跟随由哨兵选举出来的新服务器！

3.大家可以进入./redis-cli，输入**info，**查看你的状态信息；

![Center 1][]

## 三、哨兵(**Sentinel)****总结** ##

1、**Sentinel**的作用：

A、Master 状态监测

B、如果Master 异常，则会进行Master-slave 转换，将其中一个Slave作为Master，将之前的Master作为Slave

C、Master-Slave切换后，master\_redis.conf、slave\_redis.conf和sentinel.conf的内容都会发生改变，即master\_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

2、**Sentinel**的工作方式**:**

1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令。

2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。

3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 。

5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 。

6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 。

7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。

若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

最后，如果大家看不太懂，推荐大家看两个博客，就明白了！

1.http://blog.csdn.net/zbw18297786698/article/details/52891695  
2.http://blog.csdn.net/candy\_rainbow/article/details/52842402

===========================================================================

### 心跳检测 ###

在命令传播阶段，**从服务器默认以每秒一次的频率**，向主服务器发送命令：

**REPLCONF ACK <replication\_offset>** //replication\_offset是从服务器当前的复制偏移量。

心跳检测的作用：检测主服务器的网络连接状态；辅助实现min-slaves选项；检测命令丢失。

检测主从服务器的网络连接状态

通过向主服务器发送INFO replication命令，可以列出从服务器列表，可以看出从最后一次向主发送命令距离现在过了多少秒。

![Center 2][]

lag的值应该在0或1之间跳动，如果超过1则说明主从之间的连接有故障。

辅助实现min-slaves选项

Redis可以通过配置**防止主服务器在不安全的情况下执行写命令**；

min-slaves-to-write 3

min-slaves-max-lag 10

上面的配置表示：从服务器的数量少于3个，或者三个从服务器的延迟（lag）值都大于或等于10秒时，主服务器将拒绝执行写命令。这里的延迟值就是上面INFOreplication命令的lag值。

检测命令丢失

如果因为网络故障，主服务器传播给从服务器的**写命令在半路丢失**，那么当从服务器向主服务器发送REPLCONF ACK命令时，主服务器将发觉从服务器当前的**复制偏移量**少于自己的复制偏移量，然后主服务器就会根据从服务器提交的复制偏移量，在复制积压缓冲区里面找到从服务器缺少的数据，并将这些数据重新发送给从服务器。

主服务器向从服务器**补发缺失数据**这一操作的原理和部分重同步操作的原理非常相似，它们的区别在于：补发缺失数据操作在主从服务器没有断线的情况下执行，而部分重同步操作则在主从服务器断线并重连之后执行。

微信扫一扫---打赏

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIyNDA0NTU_size_16_color_FFFFFF_t_70][]

[https_blog.csdn.net_yswKnight_article_details_78158540]: https://blog.csdn.net/yswKnight/article/details/78158540
[Center]: /images/20220516/375729b7094f4557aaf3911914e5f59d.png
[Center 1]: /images/20220516/457e4cc4244748e8b4365d16e02371ef.png
[Center 2]: /images/20220516/8a505cf890874523b886469be33d8080.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTIyNDA0NTU_size_16_color_FFFFFF_t_70]: /images/20220516/96c66f64a9194738808b1f3e5128628d.png