缓存成神路：Redis哨兵模式原理和部署，你不懂其实就这么简单

大家好，我是发财！上篇文章给大家分享下Redis 主从复制作用及场景模式和原理，今天来讲讲主从复制和哨兵模式配合使用！有不对的地方也可以在评论区留言探讨，也可以转发关注下我以后会长期分享！
哨兵模式
哨兵模式介绍

在将哨兵模式之前，先来说说主从复制的缺点吧。

如果主节点出了问题，那么主节点不在提供服务，需要手动的将从节点切换成主节点。

所以这个时候哨兵模式就出现啦，当主节出现故障时，Redis Sentinel 会自动的发现主节点的故障并转移，并通知应用方，实现高可用。

下面是 Redis 官方文档对于哨兵功能的描述：

监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前 Redis 服务的主节点地址。
通知（Notification）：哨兵可以将故障转移的结果发送给客户端。
哨兵模式的结构拓扑图大概如下，也是照书上画的哈哈

大意就是：

每一个哨兵节点会监听其他的哨兵节点以及 Master 和所有的 Slave
所有哨兵节点会定期的 ping 主节点，监控是否正常
如果认为主节点出现故障的哨兵数量达到阈值，就判定主节点死掉，主节点就会客观下线
主节点客观下线后，哨兵节点通过选举模式在 Slave 中选择出一个升级为主节点
其他的 salve 指向新的主节点
原来的 Master 变成 Slave，并且指向新的主节点
引用官方哨兵模式处理流程：

每个 Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的 Master 主服务器、Slave 从服务器以及其他 Sentinel（哨兵）进程发送一个 PING 命令。

如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）。
如果一个 Master 主服务器被标记为主观下线（SDOWN），则正在监视这个 Master 主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认 Master 主服务器的确进入了主观下线状态。
当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认 Master 主服务器进入了主观下线状态（SDOWN）， 则 Master 主服务器会被标记为客观下线（ODOWN）。
在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有 Master 主服务器、Slave 从服务器发送 INFO 命令。
当 Master 主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master 主服务器的所有 Slave 从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
若没有足够数量的 Sentinel（哨兵）进程同意 Master 主服务器下线， Master 主服务器的客观下线状态就会被移除。若 Master 主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master 主服务器的主观下线状态就会被移除。
哨兵模式部署

1. 首先到我们 Redis 安装目录下，发现有 sentinel.conf，我们把它移到我们自己定义的文件夹中，和 redis.conf 放在一起。

mv sentinel.conf /usr/local/redis/etc/

修改 sentinel.conf 文件

port 26379
dir /usr/local/redis/etc
这里默认的是“/tmp”，如果你没有这个目录的权限就需要换啦，换一个你有权限的目录，不然后果自负哈哈，我就是从坑里爬起来的。

sentinel monitor mymaster 192.168.252.53 6379 2
sentinel auth-pass mymaster 123456
设置监控的主节点，2 是一个阈值，代表有两台或两台以上哨兵判断主节点 Redis 不通的话就认定这个节点有问题，实行故障转移。

daemonize yes 后台启动
logfile “/usr/local/redis/logs/redis_sentinel-26379.log” 加上日志 ，不加也无所谓

注意，这个 auth-pass 要放在放在 monitor 下面，不然会报错。

配上一些参数说明：

将 sentinel.conf 复制两份，分别为 sentinel26389.conf、sentinel26399.conf 并修改这个文件中的 prot 和 logfile：

port 26389
logfile “/usr/local/redis/logs/redis_sentinel-26389.log”
port 26399
logfile “/usr/local/redis/logs/redis_sentinel-26399.log”
4. 启动哨兵

redis-sentinel /usr/local/redis/etc/sentinel.conf
redis-sentinel /usr/local/redis/etc/sentinel26389.conf
redis-sentinel /usr/local/redis/etc/sentinel26399.conf
查看一下，三个哨兵都已经启动了。

5. 验证

先看看启动日志，，下图所示表明监控了三个节点。如果没有监控到这三个节点，证明没有配置成功。

没有配置成功的原因可能是防火墙导致的，关闭调防火墙。还有就是如果 redis-server 重启过，那在 sentinel.conf 中生成的 pid 和最后的运行添加的几行需要删除掉，下图这些。然后重新运行。

好的，日志看的没有问题，如果不想看日志，我们来这样验证，我们已经启动了三个 Redis 服务，三个哨兵。我们现在把 Master 杀死看看是什么情况。

kill -9 19688
看日志，三个哨兵的监控日志基本上是一样的，下图贴出三个哨兵的日志，我们就看一下第一个哨兵的日志分析一下。

看上图，启动哨兵的时候，监控到了 Master 6379 和两个 Slave 6389 和 6399，以及另外两个哨兵，26389 和 26399。

然后 sdown master mymaster 192.168.252.53 6379 表示刚刚我们杀死的 Master 服务。

这个时候有一个哨兵表示其主观下线，等到 odown 达到我们设置的 2 时，表明有两个哨兵表示其主观下线，那么就认为 6379 这个 Master 已经客观下线。

然后通过选举，选取 26399 这个哨兵为这三个哨兵的领导者 (leader)。

23699 这个 leader 在 salve 中选择 6399 转为 Master，将 6389 这个 Slave 指向新的 Master 6399；这个时候重启 6379 这个 Redis 服务，将 6379 这个 Slave 指向新的 Master 6399。


好，下面我们来看看界面

可以看到 Master 已经切换到 6399 服务了，现在我们再切换一下，看下面这张图应该很清晰啦。
到此为止，哨兵模式就搭建好啦，当 Master 挂掉时，会自动的将一个 Slave 升级成 Master 并将其他的 Slave 指向新的 Master，重新把原来的 Master 启动后，会变成 Slave 执行新的 Master。

推荐阅读
刚刚入驻CSDN，有不对的地方可以在评论区留言，觉得不错的朋友希望能得到您的转发支持，这是对我最大支持，同时可以持续关注我，每周定期会分享3到4篇精选干货！