Redis——基于主从复制实现高可用（redis-sentinel）

一.sentinel哨兵模式介绍

Sentinel(哨兵)是用于监控redis集群中Master状态的工具，是Redis
的高可用性解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel是redis高可用的解决方案，sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。

sentinel可以让redis实现主从复制，当一个集群中的master失效之后，sentinel可以选举出一个新的master用于自动接替master的工作，集群中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。

图来自网络

redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。Sentinel由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

Sentinel作用：

• 1）Master状态检测

• 2）如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave。

• 3）Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

Redis配置文件/etc/redis/sentinel.conf中几个重要的配置项含义

port 26379

sentinel监听端口，默认是26379，可以修改。

daemonize  no

默认情况下，sentinel是不是在后台运行的，如果需要在后台运行，把该项的值更改为yes。

sentinel auth-pass  

设置连接master和slave时的密码，注意的是sentinel不能分别为master和slave设置不同的密码，因此master和slave的密码应该设置相同。

配置示例：

sentinel auth-pass mymaster 0123passw0rd

sentinel monitor    

告诉sentinel去监听地址为ip:port的一个master，这里的master-name可以自定义，quorum是一个数字，指明当有多少个sentinel认为一个master失效时，master才算真正失效。master-name只能包含英文字母，数字，和“.-_”这三个字符
需要注意的是master-ip 要写真实的ip地址而不要用回环地址（127.0.0.1）。

    所以一般设置的redis的主从个数为奇数个。

    配置示例：

    sentinel  monitor  mymaster  172.25.83.1  6379  2

sentinel down-after-milliseconds   

这个配置项指定了需要多少失效时间，一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒，默认为30秒

配置示例：

sentinel  down-after-milliseconds  mymaster  10000

 sentinel failover-timeout  

failover-timeout 可以用在以下这些方面：
1.同一个sentinel对同一个master两次failover之间的间隔时间。
2 . 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
3.当想要取消一个正在进行的failover所需要的时间。
4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个时件，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了。

配置示例：

sentinel  failover-timeout  mymaster1  180000

二.使用（redis-sentinel）配置高可用

前提：

这个实验是基于redis的主从复制的，具体的配置请看上一篇博客，我们在配置好一主一从的前提下，新增加一从——server3（该从的配置同server2）

具体的安装redis就不展示了，这里只显示配置server3的redis：

重启服务：

查看redis的信息：此时的存储数据是“mengmeng”，master是server1，salve是server2和server3

[root@server1 ~]# redis-cli
127.0.0.1:6379> get name
127.0.0.1:6379> info replication

配置redis高可用实验过程如下所示：

第一步：将sentinel配置文件拷贝到/etc/redis目录中并编辑

[root@server1 redis-5.0.3]# cp sentinel.conf /etc/redis/
[root@server1 redis-5.0.3]#cd  /etc/redis
[root@server1 redis]# vim sentinel.conf
 protected-mode  no        #关闭保护模式，可以进行远程连接
 sentinel monitor mymaster 172.25.27.1 6379 2      #监控的名称是mymaster，ip是 172.25.27.1，端口是6379，2表示裁决，三台主机只有半数以上同意方可切换。
 sentinel down-after-milliseconds mymaster 10000    #10秒收不到master的数据包，就认为master已经down。

第二步：为了方便，将server1配好的sentinel配置文件发送到server2

注意：将server1上配好的sentinel文件发送给server2，一定要在server1开启sentinel之前。这是因为sentinel是一个动态的服务。如果开启sentinel，然后再发送，那么sentinel配置文件就不会发生改变。这时，在server2上启动sentinel会报错。

第三步：在server1/2/3开启服sentinel务

[root@server1 redis]# redis-server /etc/redis/sentinel.conf --sentinel

server1:

server2:

此时的server1也可以查看到：

server3：

此时的server1/2也可以查看到!

我们server1/2/3都可以看到主从复制和sentinel的变化，所以我们后面的实验变化图就不一一都放上，只挑一台主机的就好

查看sentinel的状态：

第四步：测试

重新开server1的终端并shutdown模拟master坏掉（因为之前的终端被sentinel的开启占用）

我们可以看到变化的过程（只是主从复制坏了，sentinel没坏所以看到过程）：

查看redis主从复制的状态：

第五步：将server1恢复，加入主从复制

因为server1现在是slave，所以需要配置

查看变化过程:

重新查看redis主从复制状态：

• server1已经加入主从复制

• server1现在是slave