Redis的哨兵（高可用）

实验环境：用一主两从来实现Redis的高可用架构。

一、Redis哨兵

Sentinel 进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候， 可以实现Master和Slave服务器的切换，保证系统的高可用，此功能在redis2.6+的版本已引用，Redis的 哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版本。

每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活” 着，如果发现对方在指定配置时间(此项可配置)内未得到回应，则暂时认为对方已离线，也就是所谓的” 主观认为宕机” (主观:是每个成员都具有的独自的而且可能相同也可能不同的意识)，英文名称： Subjective Down，简称SDOWN。

有主观宕机，对应的有客观宕机。当“哨兵群”中的多数Sentinel进程在对Master主服务器做出SDOWN 的 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判 断，这种方式就是“客观宕机”(客观:是不依赖于某种意识而已经实际存在的一切事物)，英文名称是： Objectively Down， 简称 ODOWN。

通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改 相关配置，并开启故障转移（failover）。

Sentinel 机制可以解决master和slave角色的自动切换问题，但单个 Master 的性能瓶颈问题无法解决,类 似于MySQL中的MHA功能。

Redis Sentinel中的Sentinel节点个数应该为大于等于3且最好为奇数。

sentinel中的三个定时任务：

• 每10秒每个sentinel对master和slave执行info
  • 发现slave节点
  • 确认主从关系
• 每2秒每个sentinel通过master节点的channel交换信息(pub/sub)
  • 通过sentinel__:hello频道交互
  • 交互对节点的“看法”和自身信息
• 每1秒每个sentinel对其他sentinel和redis执行pi

 二、哨兵的实验过程

在所有阶段中关闭 protected-mode no

1、在master节点中

#编辑配置文件

[root@redis-node1 ~]# cd redis-7.4.0/

[root@redis-node1 redis-7.4.0]# cp sentinel.conf /etc/redis/

[root@redis-node1 redis-7.4.0]# vim /etc/redis/sentinel.conf

protected-mode no #关闭保护模式

port 26379 #监听端口

daemonize no #进入不打如后台

pidfile /var/run/redis-sentinel.pid #sentinel进程pid文件

loglevel notice #日志级别

sentinel monitor mymaster 172.25.254.10 6379 2 #创建sentinel监控监控master主机，2表示必须得到2票

sentinel down-after-milliseconds mymaster 10000 #master中断时长，10秒连不上视为master下线

sentinel parallel-syncs mymaster 1 #发生故障转移后，同时开始同步新master数据的slave数量

sentinel failover-timeout mymaster 180000 #整个故障切换的超时时间为3分钟

####复制配置文件到其他阶段

[root@redis-node1 redis-7.4.0]# scp /etc/redis/sentinel.conf root@172.25.254.20:/etc/redis/

[root@redis-node1 redis-7.4.0]# scp /etc/redis/sentinel.conf root@172.25.254.30:/etc/redis/

 2、启动服务

[root@redis-node1 redis-7.4.0]# redis-sentinel /etc/redis/sentinel.conf

3、测试

把node1停掉之后，会重新选举一个master，然后node1变为slave，在这里我们可以看到node1停了之后，node2变成了master：

切换到node2查看：

等待一会再查看，slave也添加上来啦：

三、在整个架构中可能会出现的问题

问题：

在生产环境中如果master和slave中的网络出现故障，由于哨兵的存在会把master提出去；当网络恢复后，master发现环境发生改变，master就会把自己的身份转换成slave；master变成slave后会把网络故障那段时间写入自己中的数据清掉，这样数据就丢失了。

解决：

master在被写入数据时会持续连接slave，mater确保有2个slave可以写入我才允许写入；如果slave数量少于2个便拒绝写入。

#在matster中设定

[root@redis-node2 ~]# redis-cli

127.0.0.1:6379> CONFIG GET min-slaves-to-write

1) "min-slaves-to-write"

2) "0"

127.0.0.1:6379> CONFIG set min-slaves-to-write 2

OK

127.0.0.1:6379> CONFIG GET min-slaves-to-write

1) "min-slaves-to-write"

2) "2"

#如果要永久保存写到配置文件中/etc/redis/6379.conf