Redis (三) —— 高可用的哨兵模式架构

• 1. 哨兵模式的高可用

• 2. 哨兵模式的工作原理概述

• 3. 搭建哨兵模式

• 4. 哨兵模式测试

• 5. 哨兵模式架构优缺点

• 6. 简单谈谈我对哨兵架构的理解

建议：阅读此篇文章前，需要对redis主从机制有一定了解，如果你还不太了解，请阅读我的这篇文章：Redis (二) —— 高性能的主从模式架构

哨兵模式的高可用

哨兵模式的高可用：哨兵模式是redis主从模式的plus版，在主从模式的redis树状拓扑结构基础上，增加了sentinel监控集群。

sentinel模式解决了主从模式的一个非常致命的问题：主从模式下，主节点发生宕机，开发人员感知到这个问题后再去 人工对主节点进行更换，从主节点不可用到更换主节点的这段时间内，项目的业务不可用，这对于生产来说是致命的。

Redis Sentinel是Redis的真正高可用实现方案，在实际的生产环境中。对提高整个系统的高可用性是非常有帮助的。

redis主从模式的“高可用“是有停产风险的“高可用"

Redis主从模式下，主节点发生故障不可达，需要人工对主节点进行变更以及故障转移。

1）主节点发生故障，client连接主节点失败，同时从节点复制主节点数据进程失败。如下图所示 客户端也没办法访问主节点，整个生产环境项目就停产了。

2）主节点宕机后，开发运维人员感知到主节点宕机，一般是服务使用方通知服务不可用或者系统报警。接到报警或者通知，需要选择slave节点作为主节点来提供服务，这里选择对slave01执行slaveof no one命令使其成为主节点。

3)更新应用方的主节点信息，重新启动项目。

4)对另一个slave节点执行命slaveof newMasterIP newMasterPort

5)宕机的redis主节点恢复后，执行slaveof newMasterIP newMasterPort 去复制新的主节点，自己就成为了从节点

总结：在主从模式下，这五个步骤都需要手动在各个去执行这些命令，这个过程明显就不是高可用了，为了让这些过程能够自动化，且能在极短的时间内完成，使得具有高可用的特性，Redis Sentinel正是用于自动化完成这些工作。sentinel模式相对于主从模式，多了一个能自动化监控redis主从数据节点，并能自动发现故障主节点且能完成故障转移的sentinel监控集群。

对比主从模式，Sentinel模式能自动完成上述的五个步骤，自动完成故障发现和故障转移，并通知客户端项目。客户端能在不重启应用的情况下切换redis主节点，从而实现真正的高可用。

哨兵模式的工作原理概述

Redis Sentinel是一个分布式架构，包括若干个Sentinel节点和Redis数据节点，Sentinel节点主要负责对数据节点的进行监控，而且Sentinel节点也会监控彼此。

Sentinel节点定时的心跳检测发现某个数据节点或者Sentinel节点不可达，会对节点做下线标识。如果是主节点不可达，则Sentinel集群各个节点进入“协商“阶段，当大部分监控节点认为主节点下线了，则监控集群进入“监控节点选举阶段“，选出一个Sentinel节点来完成 故障转移工作。通知客户端主节点已经变更。

总结：上述的故障发现，故障转移，通知客户端等工作都是自动化的，从而保证了Redis的高可用

下图是Sentinel架构模式图

如上图所示，所有的Sentinel节点都会对集群中的所有节点进行定期的心跳检测，监控节点是否正常，特别是redis主节点，一旦达成下线标识且“协商“一致就会对主节点自动进行故障转移。

故障转移步骤：

1）主节点出现故障，两个从节点失去主节点的联系，主从复制失败。

2）Sentinel集群中某个节点率先发现主节点下线，与所有Sentinel节点进行协商。

3）监控节点集群对主节点故障下线协商一致，选举出sentinel-1作为本次故障转移的领导者。

4）Sentinel-1执行了故障转移，和主从模式故障转移是一样的，只不过这里是自动完成，不需要人工介入。

Sentinel主要工作：

监控：Sentinel节点定期检查监控节点和数据节点是否可达。

通知：Sentinel节点会将故障转移的结果通知客户端。

主节点故障转移：主节点下线，选中一个从节点晋级为主节点，其他从节点重新指向新主节点。

客户端连接：客户端初始化连接的是Sentinel节点集合，通过Sentinel节点间接获取主节点信息。

Sentinel集群的特性：

1）Sentinel模式是分布式集群部署，本身具有高可用性。

2）对于节点的故障判断是经过集群内“协商“的，判断数量过了一定值后才会断定故障下线。

搭建哨兵模式
注意：哨兵模式是在主从模式架构的基础上实现的高可用

sentinel模式下必须要有树状拓扑结构的Redis主从节点，主从模式架构的搭建见我这一篇文章:Redis (二) —— 高性能的主从模式架构，哨兵模式架构比主从模式多了分布式集群部署的Sentinel节点。

Sentinel分布式集群搭建：如下图所示，目录ms是我搭建的主从模式目录，而sentinel是我用来搭建Sentinel模式架构文件目录。

我搭建好的主从集群进程信息如下：

[root@JackDKing jdkredis]# ps -ef|grep redis
root      6298     1  0 Mar23 ?        00:47:52 redis-server 0.0.0.0:6380
root     20314 20162  0 09:32 pts/0    00:00:00 grep redis
root     25967     1  0 Mar21 ?        01:07:08 redis-server 0.0.0.0:6381 
root     26687     1  0 Mar21 ?        01:10:55 redis-server 0.0.0.0:6379 

三个节点的拓扑图如下： 启动Sentinel节点：

1)在sentinel下创建3个子目录sen01,sen02,sen03，并准备好基本环境

cd sentinel&mkdir sen01&mkdir sen02&mkdir sen03  #创建三个sentinel节点的目录
mkdir data& mkdir logs   #为三个节点创建数据目录和日志目录
tar -xzvf redis-5.0.2.tar.gz & mv redis-5.0.2  ./sentinel/sen01 # 解压redis压缩包,并将redis复制到sen01目录下
make & make install    # 编译redis 并 安装redis

2)sentinel启动使用的是sentinel.conf配置文件

protected-mode no 
port 26379  #端口
daemonize yes #后台启动
pidfile /var/run/redis-sentinel_26379.pid
logfile "/usr/local/jdkredis/sentinel/sen01/logs/redis-sentinel.log"
dir /usr/local/jdkredis/sentinel/sen01/data
#设置 主名称 ip地址 端口号 参入选举的哨兵数
#配置哨兵需要监控的主节点ip和端口，最后的2代表，如果有2个哨兵主观认为主节点down了，
#那么就客观认为主节点down掉了，开始发起投票选举新主节点的操作。多个主节点配置多个。
sentinel monitor mymaster 192.168.3.9 6379 2
# switched off.
#设置连接master和slave时的密码，注意的是sentinel不能分别为master和slave设置不同的密码，
#因此master和slave的密码应该设置相同。
sentinel auth-pass mymaster <redis主节点密码>
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

其他节点只需要将sentinel.conf复制到其他两个节点目录下，修改端口和pidfile内容就行。

sen02:

port 26380  #端口
pidfile /var/run/redis-sentinel_26380.pid
logfile "/usr/local/jdkredis/sentinel/sen02/logs/redis-sentinel.log"
dir /usr/local/jdkredis/sentinel/sen02/data

sen03:

port 26381  #端口
pidfile /var/run/redis-sentinel_26381.pid
logfile "/usr/local/jdkredis/sentinel/sen03/logs/redis-sentinel.log"
dir /usr/local/jdkredis/sentinel/sen03/data

除了以上几个参数不同外，其他参数都一样。

启动命令：

[root@JackDKing sentinel]# redis-server  ./sen01/sentinel.conf
[root@JackDKing sentinel]# redis-server  ./sen02/sentinel.conf
[root@JackDKing sentinel]# redis-server  ./sen03/sentinel.conf

查看sentinel集群进程：

[root@JackDKing sentinel]# ps -ef|grep redis
root      6298     1  0 Mar23 ?        00:48:07 redis-server 0.0.0.0:6380
root     21819 20162  0 10:18 pts/0    00:00:00 grep redis
root     25967     1  0 Mar21 ?        01:07:24 redis-server 0.0.0.0:6381               
root     26553     1  0 Mar21 ?        01:30:33 redis-sentinel *:26379 [sentinel] 
root     26560     1  0 Mar21 ?        01:30:34 redis-sentinel *:26380 [sentinel] 
root     26566     1  0 Mar21 ?        01:30:17 redis-sentinel *:26381 [sentinel] 
root     26687     1  0 Mar21 ?        01:11:12 redis-server 0.0.0.0:6379  

结果显示，sentinel集群启动成功！！！

哨兵模式测试

登入sentinel节点：redis-cli -h 192.168.3.9 -p 26379

显示所有 主节点的信息：sentinel masters

从上图信息可知sentinels监控的主节点是6379端口的redis节点。

查看sentinel集群节点信息： info sentinel

上图最后一行 显示的是主节点地址和端口以及从节点数量和sentinel节点的数量，我们启动的sentinel节点数量为3。

哨兵模式架构优缺点

优点：

1)哨兵模式解决了主从模式的单点风险，实现了redis真正的高可用性。

2)哨兵模式具有自动执行redis故障转移，避免了人工的介入。

缺点：

1)哨兵模式架构不具有无限伸缩的能力，无法在线扩容(动态添加，删除节点)，必须在启动的时候就分配给它尽可能大的内存，使用量不高的时候会造成内存资源的浪费，因此性能收到主节点内存影响。

简单谈谈我对哨兵架构的理解

生产环境不建议使用主从模式，而是使用高可用的Sentinel哨兵架构模式，当我们项目系统对redis内存量要求不高的时候，比起集群模式，哨兵模式更适合，它能拥有单机redis所有的功能，而集群模式会舍弃一些功能，例如mset，mget等批量key的操作。但如果系统对redis内存量依赖特别大且未来使用量无法估算的时候，建议使用集群模式，毕竟它既高可用也易伸缩。