Redis哨兵 Sentinel 主要解决主节点故障恢复自动化问题，提供主节点的自动故障转移，实现高可用性。哨兵系统包括定时任务、主观下线、客观下线和故障转移流程，确保在主节点故障时能选出新的主节点。哨兵节点通过监控、消息通知、自动故障转移和配置中心功能，协助管理Redis集群。在实际部署中，哨兵至少需要三个实例，并通过特定配置防止数据丢失。
有眼光啊，这么多文章你点开了我，缘分，如果我没猜错的话，你是个有梦想的人，是个热爱技术的人，我们一起 手牵手撒 ？（暗示关注~~）
捞一下前面的Redis文章，这是一个系列啊，后续还会出更多Redis的面试篇，Redis面试杀器让你驰骋职场，明智的小伙伴早就关注方便以后学习了，你呢？
我们前面文章说的RDB和AOF是为了解决单机redis的数据存储问题，主从复制可以实现数据冗余，侧重于解决数据的多机热备份。
但是主从复制中存在着一个问题就是故障恢复无法自动化，而redis中的哨兵机制，基于Redis主从复制，主要作用便是解决主节点故障恢复的自动化问题，进一步提高系统的高可用性
Redis哨兵Sentinel，核心功能是主节点的自动故障转移，管理多个Redis服务器，哨兵节点不存储数据
持久化： 持久化最容易理解，主要就是将数据备份，将数据备份到硬盘上，不会因为机器宕机停电等造成数据丢失
主从复制： 复制主要实现了多个机器的备份，以及对于读操作的负载均衡和简单的故障恢复（哨兵和集群都是在复制的基础上实现高可用的）存在缺陷：存储能力受到单机限制，写操作无法负载均衡，故障无法自动恢复
哨兵模式： 在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。
集群： 通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。
了解哨兵Sentinel
提到哨兵，大家想到的是什么呢？（科幻迷的我瞬间想到x战警中无所不能，然后把变种人干趴下的哨兵），在那里边是谁变异了，就干掉谁\
那么Redis中哨兵是干啥的呢？我们上节说到主从架构是一主多从，主可写可读，从只能读，那要是这个主节点宕机了，谁来对外提供写服务呢？
你不就是主节点挂了吗，我在众多从节点中选出一个做为新的主节点不就OK啦
对了，哨兵就是起这个作用的，那如果原来的主节点突然好了，这时的主节点是原主节点还是通过哨兵后选出的主节点呢？答案是通过哨兵选出的节点是主节点，也就意味着主节点宕机之后再次连接便失去了它的主节点的身份了
我们来看下Redis官方对哨兵功能的介绍：
- 集群监控： 监控Redis master主和slave从进程是否正常运行
- 消息通知： 从如果Redis实例有故障，哨兵可以发送报警信息和故障转移结果发送到管理员
- 自动故障转移： 主节点不能正常工作时，可以将失效主节点其中一个从节点升级为新的主节点
- 配置中心： 客户端初始化时通过哨兵来获得Redis服务的主节点地址
其中，集群监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移，消息通知和配置中心是和客户端的交互中体现
我们知道了它是干啥的，下一步就是需要了解它是如何做到的，知其然，然后知其所以然~
典型的哨兵架构如下图：
由两部分组成，哨兵节点和数据节点：
- 哨兵节点：监哨兵系统由一个或者多个哨兵节点组成，哨兵节点是特殊的Redis节点，不存储数据
- 数据节点：主节点master和从节点slave都是数据节点
关于哨兵的工作原理，主要是理解定时任务、主观下线和客观下线的几个概念
1）定时任务： 每个哨兵节点维护了3个定时任务，分别是向主从发送info命
令获取最新的主从结构、通过发布订阅获取其它哨兵节点信息、通过向其它节点发送ping命令进行心跳检测
2）主观下线： 在心跳检测中，如果其它节点超过一定时间未回复，哨兵节点会将其进行主观下线，即一个哨兵节点主观的判断下线
3）客观下线： 哨兵节点对主节点进行主观下线之后，会通过sentinel is-master-down-by-addr命令向其它哨兵节点询问该主节点的状态，如果判断该主节点主观下线的哨兵数量达到一定的数值，则对该主节点进行客观下线
客观下线是主节点才有的概念！ 如果从节点和哨兵节点发生故障，被哨兵主观下线之后，不会有后续的客观下线和故障转移操作
故障转移流程
1、 选举哨兵领导者： 当主节点被判断主观下线之后，各个哨兵节点会进行协商，选举出一个哨兵领导者，由该领导者进行故障转移操作，监视该主节点的所有哨兵都可能成为领导者
选举使用的算法是Raft算法，基本思想就是先到先得；在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其它哨兵，则会同意A成为领导者
一般来说，哨兵领导者选择的很快，谁先完成客观下线，一般谁就能成为哨兵领导者\
2、 选择新的主节点：领导者哨兵开始故障转移操作，在从节点中选择出新的主节点；
原则是，先过滤掉不健康的从节点，选择优先级最高的从节点（通过slave-priority设置），若优先级无法区分，则选择复制偏移量最大的从节点，若扔无法区分，则选择runid最小的从节点
runid是服务器启动时自动生成，一定能找出最小的节点
不了解复制偏移量的看----> 震惊！各大互联网公司中的Redis服务器竟…
3、更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点
4、 设置原主节点：将已经下线的主节点(即6379)设置为新的主节点的从节点，当6379重新上线后，它会成为新的主节点的从节点
Redis哨兵切换主备时的数据丢失问题
数据丢失主要分为以下两种情况：
- 异步复制导致数据丢失
- 脑裂导致数据丢失
异步复制丢失是因为master到slave的复制是异步的，如果数据还未复制完成，master宕机了便会造成数据丢失；
脑裂，master所在机器突然脱离了正常网络，跟别的节点无法连接，但是实际上这个master没有挂掉，还活着，哨兵会认为这个主节点挂掉了，重新选出一个新的主节点，此时便存在两个master节点了
此时虽然某个slave被切换成了master，但是可能客户端还未进行切换，还是连接原来的master，继续向原来master节点发送数据，造成数据丢失
解决数据丢失
我们一般通过两个参数来解决：
- min-slaves-to-write 1
- min-slaves-max-lag 10
要求至少有1个slave，数据复制和同步的延迟不能超过10秒，如果说一旦所有slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了。
1）减少异步复制的数据丢失
有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内
2）减少脑裂的数据丢失
如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求，这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失
上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求，因此在脑裂场景下，最多就丢失10秒的数据
一些其他
- 哨兵至少需要三个实例，来保证自己的健壮性
- 哨兵+主从结构不会保证数据零丢失，只能保证高可用性
- 哨兵节点本质是Redis节点，每个哨兵节点只需要配置监控主节点，便可以自动发现其他哨兵节点和从节点
- 在哨兵节点启动和故障转移过程中，哨兵的配置文件会被重写
实战
接下来演示一个简单的哨兵系统的部署来帮助大家理解，包含一个主节点，两个从节点和三个哨兵节点，均部署在本机localhost上，通过端口号区别
部署主从节点
哨兵系统的主从节点和普通的主从节点没啥区别，不需要额外的配置，我们设置主节点端口号是6379，从节点端口号是6380和6381
#redis-6379.conf
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
#redis-6380.conf
port 6380
daemonize no
logfile "6380.log"
dbfilename "dump-6380.rdb"
slaveof localhost 6379
#redis-6381.conf
port 6381
daemonize no
logfile "6381.log"
dbfilename "dump-6381.rdb"
slaveof localhost 6379
配置完上面的三个配置文件之后，我们通过命令启动主从节点
redis-server redis-6379.conf
redis-server redis-6380.conf
redis-server redis-6381.conf
节点启动后，我们连接主节点，通过info Replication命令查看，可以看到connected_slaves:2，该主节点有两个从节点
部署哨兵节点
哨兵节点本质上就是不含数据的Redis节点，3个哨兵节点的配置几乎是一样的，我们只需要修改端口号相关即可（16379、16380、16381）
#redis-16379.conf
port 16379
daemonize yes
logfile "16379.log"
sentinel monitor mymaster localhost 6379 2
其中sentinel monitor mymaster localhost 6379 2配置的含义是，该哨兵节点监控localhost这个主节点，该主节点名字是mymaster，参数2则是和主节点的故障判定有关，至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
哨兵节点的启动方式：
redis-sentinel redis-16379.conf
redis-server redis-16379.conf --sentinel
我们连接上端口号16379的客户端，通过info sentinel命令查看从节点和相应的哨兵节点信息（连接命令redis-server.exe -p 16379）
结束语
感谢大家能够做我最初的读者和传播者，请大家相信，只要你给我一
份爱，我终究会还你们一页情的。
欢迎大家关注我的公众号【左耳君】，探索技术，分享生活
哦对了，后续所有的文章都会更新到这里
https://github.com/DayuMM2021/Java
扫一扫
802
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
