DBA Redis 哨兵模式
功能概述
本篇文章紧接上一篇主从复制为基础，可点击跳转Redis 主从复制。
在Redis的主从模式下，主节点一旦宕机则需要人工进行干预将从节点晋升为主节点，同时还需要修改application链接已宕机主节点的信息等，这对于很多应用场景来说是无法接受的，我们需要的是自动化的故障转移。
为了解决这个问题，Redis在2.8版本发布了一个稳定版本的Redis Sentinel（哨兵），它解决了Redis主从需要人工干预的问题，实现高可用，在实际生产中对提高整个系统可用性是非常有帮助的。
哨兵相较于MySQL的MHA来说，它是一种持续性服务，并非MHA的一次性服务。
架构图如下所示：
每台节点机上开2个实例，一个是哨兵实例、一个是Redis服务实例。
以此组成2套集群，哨兵集群和主从集群。
哨兵集群互相地位相等，并且能够实时的监控主从集群，提供以下服务：
- 监控：Sentinel会不断的定期的检查Master以及Slave是否工作正常
- 提醒：当被监控的某个Redis服务出现问题，Sentinel会通过API向管理员或者其他应用程序发送通知
- 自动故障转移：当主服务器失联后，Sentinel将会从从服务器中选定一个新的节点作为主节点，除此之外，Sentinel还会对application返回新的主节点供application进行链接，前提是application链接的是Sentinel
哨兵本身就是一个分布式架构的集群，为什么不采用单哨兵呢？这样做有以下2点好处：
- 对于服务节点的故障判断由多个节点共同完成，可以有效防止误判
- 由于application是链接的是多个Sentinel，当某个Sentinel不可用时也不会影响application的访问与操作
哨兵集群最少3节点，与MHA与MongoDB复制集相同，当主节点失联后，只有奇数节点才能进行投票，否则会进行平票的情况。
哨兵配置
为了节省服务器资源，我将对每一个节点开启2个实例。
1个实例用于Redis的主从服务集群搭建，另1个实例用于哨兵服务集群搭建。
哨兵们并不会存储任何业务数据，仅对Redis主从架构做监控。
以下是地址规划：
| 作用 | IP地址 | 服务端口 | 哨兵端口 | 操作系统 | 配置 |
|---|---|---|---|---|---|
| Master | 192.168.0.120 | 6379 | 26379 | Centos7.3 基础设施服务器 | 2颗CPU 2G内存 20G硬盘 |
| SLAVE1 | 192.168.0.130 | 6379 | 26379 | Centos7.3 基础设施服务器 | 2颗CPU 2G内存 20G硬盘 |
| SLAVE2 | 192.168.0.140 | 6379 | 26379 | Centos7.3 基础设施服务器 | 2颗CPU 2G内存 20G硬盘 |
所有节点创建哨兵相关目录：
$ mkdir -p /usr/local/redis_cluster/redis_26379/{conf,pid,logs}
所有节点进行哨兵文件的配置：
$ vim /usr/local/redis_cluster/redis_26379/conf/redis_26379.cnf
# 输入以下信息：
# 需要更改，修改为当前节点IP即可
bind 192.168.0.120
port 26379
daemonize yes
logfile /usr/local/redis_cluster/redis_26379/logs/redis_26379.log
dir /usr/local/redis_cluster/redis_26379/
sentinel monitor mymaster 192.168.0.120 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 30000
# sentinel auth-pass mymaster password
# sentinel notification-script mymaster /root/notice.sh
参数解释：
-
sentinel monitor：
mymaster代表监听的Redis服务Master的自定义名称
2代表如果该服务失联，则至少需要几个哨兵进行确认
这里设置为如果Master服务失联，至少需要2个哨兵进行确认
一组哨兵架构可以监听多套主从复制，只需要设置不同的主节点名称即可
-
sentinel down-after-milliseconds：
哨兵认为Master多少毫秒未有心跳响应则判断失联
这里采用默认值，即30000毫秒（3分钟）
-
sentinel parallel-syncs：
在进行主从复制时，Master最多同一时刻支持多少Slave的复制请求
这里设置为1，代表所有Slave串行获取Master的RDB文件
值越大，网络需求越高，Master压力越大，同步越快
值越小，网络需求越低，Master压力越小，同步越慢
-
sentinel failover-timeout：
故障转移最大毫秒数，如超过该毫秒数则认为本次故障转移失败
默认是30000毫秒（3分钟）
这里设置为默认值
-
sentinel auth-pass：
如果Master开启安全认证，哨兵链接时通过该配置项输入认证密码
-
entinel notification-script：
服务器无法正常联通时，设定的执行脚本，通常调试使用
启动哨兵
为了实验严谨度，我们先关闭3台Redis服务，重新配置主从：
# 三台都做
$ redis-cli -h master -p 6379 shutdown
# master
$ redis-server /usr/local/redis_cluster/redis_6379/conf/redis.cnf
# slave
$ redis-server /usr/local/redis_cluster/redis_6379/conf/redis.cnf --slaveof 192.168.0.120 6379
三个节点均开启哨兵：
$ redis-sentinel /usr/local/redis_cluster/redis_26379/conf/redis_26379.cnf
登录哨兵
哨兵节点是一个特殊的Redis节点，使用以下命令进行登录：
$ redis-cli -h master -p 26379
# 关闭哨兵 redis-cli -h master -p 26379 shutdown
有以下的一些哨兵命令：
Info Sentinel # 查看哨兵信息
Sentinel Masters # 查看所有的主节点信息（Redis服务）
Sentinel master <master name> # 查看指定监听的主节点信息（Redis服务）
Sentinel slaves <master name> # 查看指定监听的从节点信息（Redis服务）
Sentinel get-master-addr-by-name <master name> # 查看监听的主节点名称与地址
Sentinel failover <master name> # 强制进行故障转移，即使主节点未宕机
Sentinel flushconfig # 刷新哨兵配置文件
如果你使用application驱动进行链接，则链接至3个哨兵节点即可。
故障模拟
关闭Master节点：
$ redis-cli -h master -p 6379 shutdown
登录Node1的哨兵：
$ redis-cli -h node1 -p 26379
查看当前的主节点：
node1:26379> Sentinel get-master-addr-by-name mymaster
1) "192.168.0.140"
2) "6379"
重启Master节点：
$ redis-server /usr/local/redis_cluster/redis_6379/conf/redis.cnf
在Node1哨兵上查看当前节点信息：
$ Sentinel slaves mymaster
选举权重
如果想指定某个从节点在故障后具有更高的优先晋升为主节点，可按照下面的方式进行配置：
$ redis-cli -h master -p 6379
master:6379> CONFIG GET slave-priority
1) "slave-priority"
2) "100"
# 默认所有从节点都是100，该值越小优先级越高
# 如果为0则永不竞选
你需要将它设置为1或者，反正是小于100且不为0的数字：
master:6379> CONFIG SET slave-priority 1
或者你也可以在搭建主从时进行配置，在服务配置文件(注意！不是哨兵配置文件)中填入该项：
slave-priority 1
