【从0到1进阶Redis】哨兵模式

小伙伴们可以看一下上一篇我的Redis笔记 —— 【从0到1进阶Redis】主从复制
这样可以更好的理解原理。

一、概述

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们有限考虑哨兵模式。Redis从2.8开始正式提供了 Sentinel（哨兵）架构来解决这个问题。

哨兵模式能够在后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵了一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 示例。

单哨兵模式：

单哨兵有两个作用：

• 通过发送命令，让 Redis 服务器返回监控其运行状态，包括主服务器和从服务器。
• 当哨兵检测到 Master 宕机，会自动将 Slave 切换成 Master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主句。

然而一个哨兵进程对 Redis 服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式：

假设主服务宕机，哨兵1先检测到这个结果，系统并不会马上进行 failover（故障转移） 过程，仅仅哨兵1主观的认为服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行 failover操作，切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

二、测试

我们目前的状态是一主二从。测试启动三个哨兵

1、配置哨兵配置文件 sentinel.conf

配置一下sentinel.conf

## sentinel-5000.conf  port 5000 sentinel nonitor mymaster 127.0.0.1 6379 1 

哨兵的全部配置在下面给大家列出来了。

2、启动哨兵

Redis 哨兵是通过 redis-sentinel 程序启动的

# 启动 redis-sentinel sentinel-5000.conf  

启动成功看到的界面：

在从机6380和6381客户端使用 slaveof 127.0.0.1 6379 命令连接主机
并查看6379信息状态：

3、测试主机下线

主机6379使用 shutdown 命令关机，查看哨兵日志：

sentinel 日志：

4、查看从机状态并重启6379服务

查看从机信息状态：

重启 6379 服务并查看三个服务状态：

三、总结

如果 Master 主节点断开了，这个时候就会从从机中随机选择一个服务器。（这里面有一个投票算法）。
如果主机此时回来了，只能归并到新的主机下，当做从机，这就是哨兵模式的规则。

优点： 1、哨兵集群，基于主从复制模式，所有的主从配置优点，它全有 2、主从可以切换，故障可以转移，系统的可用性就会更好 3、哨兵模式就是主从复制的升级，手动到自动，更加健壮  缺点： 1、Redis 不好在线扩容，集群容量一旦到达上限，在线扩容就十分麻烦 2、实现哨兵模式的配置其实是很麻烦的，里面有很多选择 

哨兵模式的全部配置

## sentinel.conf  # 哨兵 sentinel 实例运行的端口默认 26379 port 26379  # 哨兵 sentinel 的工作目录 dir /tmp  # 哨兵 sentinel 监控的 redis 主节点的 ip port # master-name 可以自己命令的主节点名字，只能由字母A-z、数字0-9、这三个字符“.“、”-“、”_”组成 # quorum 配置多少个 sentinel 哨兵同意认为主节点失联，那么这时客观上认为主节点失联了 # sentinel monitor <master-name> <ip> <port> <quorum> sentinel monitor mymaster 127.0.0.1 6379 2  # 当在 Redis 实例中开启了 requirepass foobared 授权密码，这样所有连接 Redis 实例的客户端都要提供密码 # 设置哨兵 sentinel 连接主从的密码，注意必须为主从设置一样的验证密码 # sentinel auth-pass <master-name> <password> sentinel auth-pass mymaster 123456  # 指定多少毫秒之后 主节点没有应答哨兵 sentinel 此时，哨兵主观上认为主节点下线，默认30秒 # sentinel down-after-milliseconds <master-name> <milliseconds> sentinel down-after-milliseconds mymaster 30000  # 这个配置指定了在发生 failover 主备切换时最多可以有多少个 slave 同时对新的master 进行同步， 这个数字越小，完成 failover 所需的时间就越长，但是如果这个数字越大，就意味着越多的 slave 因为 replication而不可用， 可以通过将这个值设为 1 来保证每次只有一个 slave 处于不能处理命令请求的状态。 # sentinel-parallel-syncs <master-name> <numslaves> sentinel-parallel-syncs mymaster 1  # 故障转移的超时时间 failover-timeout 可以用在以下这些方面： # 1、同一个 sentinel 对同一个 master 两次 failover 之间的间隔时间。 # 2、当一个 slave 从一个错误的 master 那里同步数据开始计算时间，直到slave 被纠正为向正确的 master 那里同步数据时。 # 3、当想要取消一个正在进行的 failover 所需要的时间。 # 4、当进行 failover 时，配置所有 slaves 指向新的 master 所需的最大时间，不过，即使过了这个超时，slaves 依然会被正确配置为指向 master，但是就不按 parallel-syncs 所配置的规则来了 # 默认三分钟 # sentinel failover-timeout <master-name> <milliseconds> sentinel failover-timeout mymaster 180000  # SCRIPTS EXECUTION  # 配置当某一事件发生时所需要指定的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。 # 对于脚本的运行结果有以下规则： # 若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10 # 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。 # 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。 # 一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行  # 通知型脚本：当sentinel有任何警告级别的时间发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配置文件配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel就无法正常启动成功。 # 通知脚本 # sentinel notification-script <master-name> <script-path> sentinel notification-script mymaster /var/redis/notify.sh  # 客户端重新配置主节点参数脚本 # 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于 master 地址已经发生改变的信息。 # 一下参数将会在调用脚本时传给脚本： # <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> # 目前 <state> 总是 “failover” # <role> 是 “leader” 或者 “observer” 中的一个。 # 参数 from-ip， from-prot，to-ip，to-port 是用来给旧的 master 和新的 master（即旧的slave）通信的 # 这个脚本应该是通用的，能被多次调用，不是针对性的。 # sentinel client-reconfig-script <master-name> <script-path> sentinel client-reconfig-script mymaster /var/redis/reconfig.sh