Redis架构之哨兵模式

柔光的暖阳◎ 2022-05-09 01:24 141阅读 0赞

#### 简介 ####

*  哨兵模式（sentinel）  
    主从复制中反客为主的自动版。哨兵(Sentinel) 是一个分布式系统，你可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossipprotocols)来接收关于Master主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。
 *  每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机” ，英文名称：Subjective Down，简称SDOWN。有主观宕机，肯定就有客观宕机。
 *  当“哨兵群”中的多数Sentinel进程在对Master主服务器做出 SDOWN 的判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，这种方式就是“客观宕机”，英文名称是：Objectively Down， 简称 ODOWN。通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改相关配置，并开启故障转移（failover）。
 *  哨兵(sentinel) 虽然有一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)。

##### 哨兵进程的作用 #####

1.  监控（monitoring）：哨兵会不断的检查master，和slave是否运作正常。
2.  提醒（notification）：当被检测的某个节点出现问题时，哨兵可以通过api像管理员或者其他应用发送通知。
3.  自动故障迁移（automatic failover)：当一个master不能正常工作时，哨兵会开启一次故障迁移操作，它将失效的master的其中一个slave升级为新的master，并让失效的master的其他slave改为复制新的master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

##### 哨兵进程的工作方式 #####

1.  每个哨兵进程以每秒钟一次的频率向整个集群的中的mater主服务器、Slave从服务器和其他哨兵进程发送一个Ping命令。
2.  如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）。
3.  如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态。
4.  当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）。
5.  在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
6.  当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
7.  没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

#### 配置哨兵模式 ####

1.  环境

*  Master主服务器配置信息：IP:192.168.127.128, Port:6379，OS:Linux
 *  Slave从服务器的配置信息：IP:192.168.127.129 Port:6379，OS:Linux
 *  在Slave从服务器上安装了一个哨兵进程（Sentinel），在Master服务器也安装了一个哨兵进程（Sentinel）。

由于两个Redis服务器都是安装在Linux操作系统上，而且这两个Redis服务器会在Master主服务器发生故障的时候会进行切换，必须保证两个Redis服务器的端口号已经增加进了防火墙，或者把两个Linux操作系统的防火墙关闭，否则会提示Master-link-Status:down，没有连接上Master主服务器。解决办法有两个：第一个办法是关闭两个Linux操作系统的防火墙；第二个办法是把各个Redis服务的端口号增加到防火墙里面，允许通过该端口号进行通信。可以先使用命令 【firewall-cmd --query-port=6379/tcp】,如果结果是 No，那就继续执行以下命令【firewall-cmd --add-port=6379/tcp】，命令执行后，返回Success，表示增加成功。这样两个Linux系统上的Redis服务器就可以顺利切换，执行哨兵模式的操作。

1.  配置（没有更改的配置项就是用默认值）

*  Master config (redis.conf)

1.1、### NETWORK 设置：
    
       bind 192.168.127.128  //绑定IP地址，可以通过ifconfig 获取Ip地址(在Linux系统下)
    
       port 6379  //保持默认值，也可以修改
    
       timeout 30  //Client 端空闲断开连接的时间
    
    
    1.2、### GENERAL 设置：
    
       daemonize yes   //默认值是no，把值修改为yes，以后台模式运行
    
       logfile /root/application/program/redis-tool/logs/redis.log  //日志文件的位置
    
    
    1.3、### SNAPSHOTTING 设置：
    
       dir /root/application/program/redis-tool/datas   //SNAPSHOTTING文件的路径
    
    
    1.4、### APPEND ONLY MODE 设置：
    
       appendonly yes  //默认值是No，意思是不使用AOF增量持久化的方式，使用RDB全量持久化的方式。把No值改成Yes，使用AOF增量持久化的方式
    
       appendfsync always

*  Slave config（redis.conf)

2.1、### NETWORK 设置：
    
        bind 192.168.127.129   //绑定IP地址，可以通过ifconfig 获取Ip地址(在Linux系统下)
    
        port 6379   //保持默认值，也可以修改
    
        timeout 30  //Client 端空闲断开连接的时间
    
    
    2.2、### GENERAL 设置：
    
        daemonize yes    //默认值是no，把值修改为yes，以后台模式运行
    
        logfile /root/application/program/redis/logs/redis.log  //日志文件的位置
    
    
    2.3、### SNAPSHOTTING 设置：
    
        dir /root/application/program/redis/datas  //SNAPSHOTTING文件的路径
    
    
    2.4、### REPLICATION 设置：
    
        slaveof 192.168.127.128 6379  //主服务器的Ip地址和Port端口号
    
        slave-serve-stale-data no  //如果slave 无法与master 同步，设置成slave不可读，方便监控脚本发现问题。
    
    
    2.5、### APPEND ONLY MODE 设置：
    
        appendonly yes  //默认值是No，意思是不使用AOF增量持久化的方式，使用RDB全量持久化的方式。把No值改成Yes，使用AOF增量持久化的方式
    
        appendfsync always

*  Sentinel config (sentinel.conf 192.168.127.129 Slave从服务器)

3.1、 ### Port 设置：
    
        port 26379  //哨兵端口号保持不变，可以修改，但是我没有修改
    
    
    3.2、### dir 设置：
    
        dir /root/application/program/redis/sentinel/  //哨兵程序的日志路径
    
    
    3.3、### Sentinel Monitor 设置：
    
        sentinel monitor mymaster  192.168.127.129 6379 1 //哨兵监控主master的地址
    
    
    3.4、### Down-After-Milliseconds 设置：
    
        sentinel down-after-milliseconds mymaster 5000 //检测主服务器宕机的时间间隔
    
        //哨兵程序每5秒检测一次Master是否正常
    
    
    3.5、### Parallel-Syncs 设置：
    
        sentinel parallel-syncs mymaster 1 //同步的个数
    
    
    3.5、### Failover-Timeout 设置：
    
        sentinel failover-timeout mymaster 60000
    
    
    3.5、### 启动：redis-sentinel
    
        redis-server sentinel.conf --sentinel & //(&有这可以Ctrl +C退到命令行，没有这个就直接退出哨兵进程)
    
        redis-sentinel /path/to/sentinel.conf & //对于 redis-sentinel 程序， 你可以用以下命令来启动 Sentinel 系统
    
    
    3.6、### 关闭：redis-sentinel
    
        pkill redis-server   //这个会关掉Redis服务器和Sentinel（哨兵）进程
    
        kill 进程号     //可以关掉指定进程号的进程

*  Master 服务器的配置详情  
    ![在这里插入图片描述][70]
 *  Slave 从服务器的配置详情  
    ![在这里插入图片描述][70 1]
 *  启动哨兵进程，开始对Master主服务器进行监控  
    ![在这里插入图片描述][70 2]

#### 哨兵模式优缺点 ####

*  优点：
    
    1.  基于主从模式，所有主从的优点，哨兵模式同样具备；
    2.  主从可以切换，故障可以转移，系统可用性更好；
    3.  主从模式的升级，系统更健壮，可用性更高。
 *  缺点：  
    Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免问题一般在上线时必须确保有足够大的空间，对资源造成浪费。

#### 结束 ####

\-无论是主从模式，还是哨兵模式，这两个模式都有一个问题，不能水平扩容，不能动态的增、删节点，限制了哨兵模式的广泛应用，并且这两个模式的高可用特性都会受到Master主节点内存的限制。实现哨兵模式的配置比较繁琐。  
redis在3.x以后的版本中提供了更为强大的集群模式，Cluster集群模式。

来源：[https://www.cnblogs.com/PatrickLiu/p/8444546.html][https_www.cnblogs.com_PatrickLiu_p_8444546.html]

[70]: /images/20220509/300d31b7cb7d499f8f0b2a4ddd3431f7.png
[70 1]: /images/20220509/7e952b2556f2446f85aaa3bbbef47f4d.png
[70 2]: /images/20220509/3b139992451449b6bfe2a4908409857a.png
[https_www.cnblogs.com_PatrickLiu_p_8444546.html]: https://www.cnblogs.com/PatrickLiu/p/8444546.html