Redis的哨兵监控模式用法

1、背景介绍

        在Redis集群中，当master宕机之后，其余的slave会一直等待，这样就会导致无法向redis中写入数据，这时候就需要从其余的slave中选取一个master，但是又能不能自动的让slave晋升为maser呢？这时候需要哨兵监控了。

Redis哨兵是为Redis提供了一个高可靠解决方案。

Redis主从复制缺点：当主机 Master 宕机以后，我们需要人工解决切换。

暴漏问题：一旦主节点宕机，写服务无法使用，就需要手动去切换，重新选取主节点，手动设置主从关系。

2、哨兵模式介绍

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

        当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

        它是反客为主的自动版，能够在后台自动监控主机是否故障，如果主机故障了，其余的从机会自动进行投票选举，得票数最多的从机将转换为 master。

3、哨兵作用、缺点

3.1 作用

• 集群监控：负责监控redis master和slave进程是否正常工作
• 消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
• 故障转移：如果master node挂掉了，会自动转移到slave node上
• 配置中心：如果故障转移发生了，通知client客户端新的master地址

3.2 缺点

• 当master挂掉的时候，sentinel 会选举出来一个 master，选举的时候是没有办法去访问Redis的，会存在访问瞬断的情况；
• 哨兵模式，对外只有master节点可以写，slave节点只能用于读。尽管Redis单节点最多支持10W的QPS，但是在电商大促的时候，写数据的压力全部在master上。
• Redis的单节点内存不能设置过大，若数据过大在主从同步将会很慢；在节点启动的时候，时间特别长；

4、哨兵工作原理详解

4.1 监控阶段

注意：

• sentinel(哨兵1)----->向master(主)和slave(从)发起info，拿到全信息。
• sentinel(哨兵2)----->向master(主)发起info，就知道已经存在的sentinel(哨兵1)的信息，并且连接slave(从)。
• sentinel(哨兵2)----->向sentinel(哨兵1)发起subscribe(订阅)。

4.2 通知阶段

        sentinel不断的向master和slave发起通知，收集信息。

4.3 故障转移阶段

        通知阶段sentinel发送的通知没得到master的回应，就会把master标记为SRI_S_DOWN,并且把master的状态发给各个sentinel，其他sentinel听到master挂了，说我不信，我也去看看，并把结果共享给各个sentinel，当有一半的sentinel都认为master挂了的时候，就会把master标记为SRI_0_DOWN。

问题来了：这时就要把master给换掉了，到底谁当Master呢？

4.4 投票方式

方式：
        自己最先接到哪个sentinel的竞选通知就会把票投给它。
剔除一些情况：

• 不在线的
• 响应慢的
• 与原来master断开时间久的
• 优先级原则

5、哨兵模式流程实现

1. 开启三个 redis 服务：6379，6380，6381。

2. 先让 6379 成为 master，其余两个服务成为它的 slave。

3. 在自定义的 /myconf 目录下新建 sentinel.conf 文件，必须是这个名字。

4. 在sentinel.conf 文件中写入：

sentinel monitor 被监控的数据库名字(随意) 192.168.198.130 6379 1

注意：上面最后一个数字 1，表示 master 宕掉后，slave 投票看让谁接替成为主机，得票数最多的成为主机。

5. 启动哨兵

redis-sentinel /myconf/sentinel.conf，这个 /myconf 目录根据自己的实际情况进行配置。

6. 当把 master shutdown 之后，开启的哨兵服务会自动从剩余的两个 slave 投票选出一个当 master，而当原来的 master 上线之后会成为 从机。

6、哨兵监控环境搭建

哨兵节点本质上是redis节点。

6.1 编辑配置文件 

新建sentinel-26379.conf文件

#端口
port 26379
#守护进程运行
daemonize yes
#日志文件
logfile "26379.log"
sentinel monitor mymaster 192.168.1.12 6379 2

参数：

• sentinel monitor mymaster 192.168.1.12 6379 2 配置的含义是：该哨兵节点监控192.168.1.12:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。 

新建sentinel-26380.conf文件

#端口
port 26380
#守护进程运行
daemonize yes
#日志文件
logfile "26380.log"
sentinel monitor mymaster 192.168.1.12 6379 2

新建sentinel-26381.conf文件

#端口
port 26381
#守护进程运行
daemonize yes
#日志文件
logfile "26381.log"
sentinel monitor mymaster 192.168.1.12 6379 2

注意：如果上面操作是同一台服务器且bind未打开的话，上面配置文件中的IP要写成127.0.0.1，否则下面启动的哨兵节点之间是不能相互访问的。 

6.2 启动哨兵节点

redis-sentinel sentinel-26379.conf

6.3 查看哨兵节点状态

7、故障转移

        每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。

        哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。

        哨兵节点本质上是redis节点。

        每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。

        在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。

7.1 演示故障转移

演示当主节点发生故障时，哨兵的监控和自动故障转移功能。

7.2 kill命令杀掉主节点

7.3 查看哨兵节点信息

此时立即在哨兵节点中使用info Sentinel命令查看。

注意：

• 如果突然查看的话，可能会发现主节点还没有切换过来，因为哨兵发现主节点故障并转移，需要一段时间。

7.4 重启6379节点

7.5 配置文件都会被改写

故障转移阶段，哨兵和主从节点的配置文件都会被改写