Redis哨兵模式的配置与原理

redis哨兵模式

redis主从虽然解决了单点导致的数据丢失问题，但是还是没有解决无缝的故障转移，也就是说在主库宕机后，从库无法自动切换为主库，需要手工去切换，在这一瞬间会对后端数据库造成极大的负载，可能直接导致后端数据宕机。

哨兵主要作用

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

监控：监控redis主库及从库运行状态；

通知：如果redis发生故障转移，可以通过邮件通知管理员；

自动故障转移：当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

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

工作原理

哨兵(sentinel) 是一个分布式系统，你可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息，并使用投票协议(agreement protocols)来决定是否执行自动故障迁移，以及选择哪个Slave作为新的Master。

每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定时间(可配置)内未回应，则暂时认为对方宕机了，这就是所谓的”主观认为宕机”Subjective Down,简称sdown)。

若“哨兵群”中的多数sentinel，都报告某一master没响应，系统才认为该master真正宕机，即客观上认为宕机，Objective Down,简称odown)，通过一定的vote算法，从剩下的slave节点中，选一台提升为master，然后自动修改相关配置。

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

Redis配置哨兵模式

配置3个哨兵和1主2从的Redis服务器来演示这个过程。

192.168.179.102主          192.168.179.103/104从

127.0.0.1:6379> role

1) "master"

2) (integer) 2100

3) 1) 1) "192.168.179.104"

      2) "6379"

      3) "2100"

   2) 1) "192.168.179.103"

      2) "6379"

      3) "2100"

Master以及slave端配置

[root@localhost ~]# cp /usr/src/redis-stable/sentinel.conf  /usr/local/redis/  --在master上修改哨兵配置如下
bind 0.0.0.0
port 26379
daemonize yes
pidfile /var/run/redis-sentinel.pid
logfile "sentinel_26379.log"
sentinel monitor mymaster 192.168.179.102 6379 2  --这个值配置好了不需要修改，即使发生故障转移，master变为slave也不需要我们去修改，哨兵会自动修改
sentinel down-after-milliseconds mymaster 30000  --master主观下线时间,默认30秒，30秒内没有回复pong，则认为下线了

sentinel parallel-syncs mymaster 1  --指定在故障转移期间，多少个slave向新的master同步得数量，如果slave是提供查询服务，则应该设置小一点更好

sentinel failover-timeout mymaster 180000  --指定故障转移超时时间，默认为3分钟

sentinel notification-script mymaster /usr/local/redis/notify.sh --设置通知脚本，发生故障转移可以向管理员发送通知（可选）

sentinel deny-scripts-reconfig yes  --禁止修改脚本，避免脚本重置

[root@localhost redis]# vim /usr/local/redis/notify.sh  --通知脚本
#!/bin/bash
#####################
TO="1239683670@qq.com"
SUBJECT="redis failover"
CONTEXT="redis failover"
echo -e "$CONTEXT"|mailx -s "$SUBJECT" "$TO"
[root@localhost redis]# chmod +x /usr/local/redis/notify.sh 

[root@localhost redis]# scp /usr/local/redis/sentinel.conf 192.168.179.103:/usr/local/redis/   --将master上配置好的配置文件拷贝到远程的slave上面
[root@localhost redis]# scp /usr/local/redis/sentinel.conf  192.168.179.104:/usr/local/redis/

[root@localhost redis]# scp /usr/local/redis/notify.sh  192.168.179.103:/usr/local/redis/
[root@localhost redis]# scp /usr/local/redis/notify.sh  192.168.179.104:/usr/local/redis/  


Master库先执行 后面从库执行
[root@localhost redis]# /usr/local/redis/bin/redis-sentinel /usr/local/redis/sentinel.conf  --启动哨兵

[root@localhost ~]# netstat -tpln | grep 26379 --每台上面依次查看
tcp        0      0 0.0.0.0:26379           0.0.0.0:*               LISTEN      20766/redis-sentine

[root@localhost ~]# /usr/local/redis/bin/redis-cli -p 26379  --主库进入哨兵端口
127.0.0.1:26379> info  sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.179.102:6379,slaves=2,sentinels=3
--可以看到该信息代表配置没有问题，至此哨兵配置成功完成

模拟故障转移

手动关闭主节点

[root@localhost ~]# /etc/init.d/redis_6379 stop  --手动将主节点进行关闭，下面是哨兵日志

20766:X 06 Apr 2020 15:02:12.489 # +sdown master mymaster 192.168.179.102 6379  --主关宕机
20766:X 06 Apr 2020 15:02:12.566 # +odown master mymaster 192.168.179.102 6379 #quorum 2/2  --客观宕机，quorum2/2为法定人数
20766:X 06 Apr 2020 15:02:12.567 # +try-failover master mymaster 192.168.179.102 6379 --开始故障转移
20766:X 06 Apr 2020 15:02:12.574 # +vote-for-leader bf889f09dcbd3539e41d06b575fc831dce9c0538 1  --开始竞选主库是谁，下面是竞选算法，省略
20766:X 06 Apr 2020 15:02:14.213 # +switch-master mymaster 192.168.179.102 6379 192.168.179.104 6379  --104变成了主库
20766:X 06 Apr 2020 15:02:14.213 * +slave slave 192.168.179.103:6379 192.168.179.103 6379 @ mymaster 192.168.179.104 6379
20766:X 06 Apr 2020 15:02:14.213 * +slave slave 192.168.179.102:6379 192.168.179.102 6379 @ mymaster 192.168.179.104 6379
20766:X 06 Apr 2020 15:02:44.253 # +sdown slave 192.168.179.102:6379 192.168.179.102 6379 @ mymaster 192.168.179.104 6379

在新竞选的主节点查看信息

[root@localhost ~]# /usr/local/redis/bin/redis-cli 
127.0.0.1:6379> role
1) "master"
2) (integer) 312126
3) 1) 1) "192.168.179.103"
      2) "6379"
      3) "311981"
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.179.103,port=6379,state=online,offset=321041,lag=1
master_replid:3bdb24c624acd76f03f0ba2e7d2335bee936b399
master_replid2:ddc0f2a7490a07d4462f53bd034731f3f2ed32b3
master_repl_offset:321186
second_repl_offset:137419
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:321186

将之前手动关闭的102节点拉起来，102就会加入到104的从库队列，再去104上查看

[root@localhost ~]# /usr/local/redis/bin/redis-cli 
127.0.0.1:6379> role
1) "master"
2) (integer) 358277
3) 1) 1) "192.168.179.103"
      2) "6379"
      3) "358132"
   2) 1) "192.168.179.102"
      2) "6379"
      3) "358277"

哨兵模式下的订阅

127.0.0.1:6379> pubsub channels  -哨兵帮我们订阅的频道，通过该频道获取主库最新数据的
1)"__sentinel__:hello"
2)127.0.0.1:6379> SUBSCRIBE __sentinel__:hello
3)Reading messages... (press Ctrl-C to quit)
4)1) "subscribe"
5)2) "__sentinel__:hello"
6)3) (integer) 1
7)1) "message"
8)2) "__sentinel__:hello"
9)3) "192.168.179.102,26379,bf889f09dcbd3539e41d06b575fc831dce9c0538,1,mymaster,192.168.179.104,6379,1"
10)1) "message"
11)2) "__sentinel__:hello"
12)3) "192.168.179.104,26379,4adf7ee7492961131ffcd0d40d8683fc11ae2294,1,mymaster,192.168.179.104,6379,1"
13)1) "message"
14)2) "__sentinel__:hello"
15)3) "192.168.179.103,26379,2fe22e2d94cc8eea00e13dffafd7563a742147a1,1,mymaster,192.168.179.104,6379,1"
16)1) "message"