Redis-sentinel是Redis实例的监控管理、通知和实例失效备援服务，是Redis集群的管理工具。在一般的分布式中心节点数据库中，Redis-sentinel的作用是中心节点的工作，监控各个其他节点的工作情况并且进行故障恢复，来提高集群的高可用性。

一、Redis Sentinel规划

一个一主多从的Redis系统中，可以使用多个哨兵进行监控任务以保证系统足够稳健。此时，不仅哨兵会同时监控主数据库和从数据库，哨兵之间也会相互监控。在这里，建议大家哨兵至少部署3个，并且使用奇数个哨兵。

二、RedisSentinel部署

1、安装Redis

在3台服务器上分别安装Redis。需要注意的是，如果要给Redis设置密码，需要在3个Redis的配置文件中设置相同的密码。

requirepass"Redis-Password"

2、设置主从复制

在2个SlaveRedis的配置文件中声明所从属的主数据库。

 slaveof192.168.1.51 7000

这里需要注意一点，如果主数据库设置了密码，需要所有Redis的配置文件中设置masterauth”Redis-Password”，包括主数据库。Sentinel可以切换主从数据库，主数据库可能会变成从数据库，因此也需要设置主数据库密码。

3、配置Sentinel.config

• 创建配置文件
  创建一个sentinel目录，新建sentinel.conf文件（Redis提供了该文件的模版）。配置文件内容如下：

##sentinel实例之间的通讯端口

daemonize yes

port 27000

#redis-master

sentinel monitor redis-master 192.168.1.51 7000 2

sentinel down-after-milliseconds redis-master 5000

sentinel failover-timeout redis-master 900000

sentinel parallel-syncs redis-master 2

sentinel auth-pass redis-master 123456

logfile "/data/bd/redis/sentinel/sentinel.log"

• 配置项说明：

1)daemonize yes

– 以后台进程模式运行

2)port 27000

– 哨兵的端口号，该端口号默认为26379。

3)logfile”/data/bd/redis/sentinel/sentinel.log”

– log文件所在地

4)sentinel monitor redis-master 192.168.1.517000 2

– redis-master是主数据的别名，考虑到故障恢复后主数据库的地址和端口号会发生变化，哨兵提供了命令可以通过别名获取主数据库的地址和端口号。

– 192.168.1.51 7000为初次配置时主数据库的地址和端口号，当主数据库发生变化时，哨兵会自动更新这个配置，不需要我们去关心。

–2，该参数用来表示执行故障恢复操作前至少需要几个哨兵节点同意，一般设置为N/2+1(N为哨兵总数)。

5)sentinel down-after-milliseconds redis-master 1000

– 如果master在多少秒内无反应哨兵会开始进行master-slave间的切换，使用“选举”机制

6)sentinel failover-timeout redis-master 5000

– 如果在多少秒内没有把宕掉的那台master恢复，那哨兵认为这是一次真正的宕机，而排除该宕掉的master作为节点选取时可用的node然后等待一定的设定值的毫秒数后再来探测该节点是否恢复，如果恢复就把它作为一台slave加入哨兵监测节点群并在下一次切换时为他分配一个“选取号”。

4、Sentinel运行

• 启动Redis和Sentinel
  配置完Redis和Sentinel之后，按顺序启动各个角色。启动顺序如下：
  Master->Slave->Sentinel,要确保按照这个顺序依次启动。
  Sentinel的启动命令和Redis类似，终端输入：

redis-sentinel /data/bd/redis/sentinel/sentinel.conf

启动成功后可以通过redis客户端工具查看当前Sentinel的信息，终端输入：

redis-cli -p 27000-h 192.168.1.51 INFO Sentinel

# Sentinel

sentinel_masters:1

sentinel_tilt:0

sentinel_running_scripts:0

sentinel_scripts_queue_length:0

master0:name=redis-master,status=ok,address=192.168.1.51:7000,slaves=2,sentinels=3

• 查看sentinel日志
  日志路径在配置文件中设置，终端输入：

tail -f/data/bd/redis/sentinel/sentinel.log

3273:X 08 Apr 10:44:14.733 # Sentinel runid is 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1

3273:X 08 Apr 10:44:14.733 # +monitor master redis-master 192.168.1.51 7000 quorum 2

3273:X 08 Apr 10:44:14.735 * +slave slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:44:14.744 * +slave slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:48:12.733 * +sentinel sentinel 192.168.1.52:27000 192.168.1.52:27000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:48:20.533 * +sentinel sentinel 192.168.1.53:27000 192.168.1.53:27000 @ redis-master 192.168.1.51 7000

+slave和+sentinel分别代表成功发现了从数据库和其他Sentinel。

• 查看sentinel.conf
  重新打开sentinel.conf文件，发现sentinel自动生成了一些信息，记录了监控过程中的状态变化。

##sentinel实例之间的通讯端口

daemonize yes

port 27000

#redis-master

sentinel monitor redis-master 192.168.1.51 7000 2

sentinel down-after-milliseconds redis-master 5000

sentinel failover-timeout redis-master 900000

sentinel parallel-syncs redis-master 2

sentinel auth-pass redis-master 123456

logfile "/data/bd/redis/sentinel/sentinel.log"

# Generated by CONFIG REWRITE

dir "/soft/sentinel"

sentinel config-epoch redis-master 0

sentinel leader-epoch redis-master 0

sentinel known-slave redis-master 192.168.1.52 7000

sentinel known-slave redis-master 192.168.1.53 7000

sentinel known-sentinel redis-master 192.168.1.52 27000 ef356da8dadb6a16268d25611942ecf001d5cb2e

sentinel known-sentinel redis-master 192.168.1.53 27000 188fa69f695fd17639ce1ee38592e894d8a14331

sentinel current-epoch 0                         

三、Sentinel验证

按照之前的步骤我们已经配置好了3台Redisnode和Sentinel集群，Redis主数据库为192.168.1.51:7000。

1、模拟主数据库故障

这里直接关闭主数据库，终端输入：

redis-cli -p 7000 shutdown

经过一段时间后，我们可以看到sentinel.log文件中增加了以下内容：

3273:X 08 Apr 10:58:08.330 # +sdown master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.385 # +odown master redis-master 192.168.1.73 7000 #quorum 2/2

3273:X 08 Apr 10:58:08.385 # +new-epoch 1

3273:X 08 Apr 10:58:08.385 # +try-failover master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.388 # +vote-for-leader 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1 1

3273:X 08 Apr 10:58:08.392 # 192.168.1.52:27000 voted for 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1 1

3273:X 08 Apr 10:58:08.393 # 192.168.1.53:27000 voted for 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1 1

3273:X 08 Apr 10:58:08.489 # +elected-leader master redis-master 192.168.1.51 7001

3273:X 08 Apr 10:58:08.489 # +failover-state-select-slave master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.580 # +selected-slave slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.580 * +failover-state-send-slaveof-noone slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.633 * +failover-state-wait-promotion slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:09.561 # +promoted-slave slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:09.561 # +failover-state-reconf-slaves master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:09.612 * +slave-reconf-sent slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.517 # -odown master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.576 * +slave-reconf-inprog slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.576 * +slave-reconf-done slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.643 # +failover-end master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.643 # +switch-master redis-master 192.168.1.51 7000 192.168.1.52 7000

3273:X 08 Apr 10:58:10.643 * +slave slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.52 7000

3273:X 08 Apr 10:58:10.643 * +slave slave 192.168.1.51:7000 192.168.1.51 7000 @ redis-master 192.168.1.52 7000

3273:X 08 Apr 10:58:15.654 # +sdown slave 192.168.1.51:7000 192.168.1.51 7000 @ redis-master 192.168.1.52 7000

+sdown 表示哨兵主观认为数据库下线
+odown 表示哨兵客观认为数据库下线
+try-failover 表示哨兵开始进行故障恢复
+failover-end 表示哨兵完成故障修复，其中包括了领头哨兵的选举、备选从数据库的选择等等较为复杂的过程
+switch-master表示主数据库从51服务器迁移到52服务器
+slave列出了新的主数据库的2个从数据库，而哨兵并没有彻底清除51服务器的实力信息，这是因为停止的实例有可能会在将来恢复，哨兵会让其重新加入进来

2、恢复故障数据库

重新启动192.168.1.51上的Redis数据库，查看sentinel.log文件，日志中增加了以下的内容：

3273:X 08 Apr 11:19:44.847 # -sdown slave 192.168.1.51:7000 192.168.1.51 7000 @ redis-master 192.168.1.52 7000

-sdown 哨兵将下线的Redis实例重新加入，并且作为新的主数据库的从数据库存在