Redis是一种流行的内存数据库，具有快速、灵活和可扩展的特性。然而，在应用程序对数据可用性和可靠性要求更高时，Redis主从复制会遇到一些限制和弊端，主机宕机之后，整个redis服务只能读不能写。为了解决这些问题，Redis引入了哨兵模式。
Redis 哨兵模式是一种用于构建高可用性 Redis 集群的解决方案。它通过监控 Redis 实例的状态并自动进行故障转移，提供了客户端重定向机制以确保应用程序可以正常访问 Redis。
其中：
- 三个哨兵：自动监控和维护集群，不存放数据，只做吹哨人
- 1主2从：用于读取和存放数据
哨兵模式能干嘛：
- 主从监控：监控reids主从是否正常运行
- 消息通知：哨兵可以将故障转移的结果发送给客户端
- 故障转移：如果Master异常，则会进行主从切换，将其中一个Slave作为新的Master
- 配置中心：客户端通过连接哨兵来获得当前Redis服务的主节点地址
- 在目录下创建（也可以从redis的解压路径中复制配置文件来重命名），内容如下：
其他配置（一般不需要配置，默认就可以）
- 同样的在目录下创建内容如下：
- 同样的在目录下创建内容如下：
- 一主二从的配置前面已介绍过，就不过多赘述：
Redis基础系列-主从复制
- 先启动一主二从，并验证主从是否正常
- 然后启动三个哨兵
看看启动成功了
我们在瞅瞅日志
6380从机会出现一段时间不能连接，自动连接之后还是从机
6381从机会出现一段时间不能连接，自动连接之后晋升为主机
我们在看看哨兵配置文件会发生什么变化
上述图片是哨兵26379的配置文件变化，其它两个哨兵的配置文件也是类似变化，这里就不在赘述。
我们再查看一下哨兵26379日志的变化
我们能明显的看到6379的主观下线，选举leader以及主master切换的日志
我们再看一下6380和6381两个从机的配置文件
6380从机明显修改了主master的配置
再看一下6381的配置文件
6381从机明显删除了主master的配置，摇身一变成为主机
其实6379宕机变化
- 三个哨兵配置文件的变化
- 2个从机配置文件发生了变化（6379启动之后也能看到发生了变化）
那我们还有一个疑问，就是6379主机master恢复之后，目前这种主从结构会不会发生变化了，我们重新启动6379redis
然后看看运行情况
居然不能写，再看看它的配置文件
看来重启之后不能恢复原有的主从结构
当一个主存配置中的master失效之后，sentinel可以选举出一个新的master，用于自动接替master的工作，主从配置中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换
SDown(主观不可用)是单个sentinel自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳，在一定时间内没有收到合法的回复，就达到了SDown的条件
sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度
ODown需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕机
当主节点被判断客观下线以后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点（兵王）并由该领导者节点，也即被选举出的兵王进行failover(故障迁移)
监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：
即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者
上图理解：横向是时间轴，sentinel1向sentinel2、sentinel3发起成为领导者申请，sentinel2和sentinel3之前没有同意过别的sentinel，所以直接同意，故而sentinel得到两票；同理sentinel2向sentinel1和sentinel3发起成为领导者的申请，之前sentinel3同意过sentinel1的申请，所以sentinel只能获得1票；sentinel3向sentinel1和sentinel2发起成为领导者的申请，由于sentinel1和sentinel2都同意过别的sentinel，故而sentinel3只能获得0票
sentinel26379.log
sentinel26380.log
sentinel26381.log
// TODO -odown 和 +odown有啥区别
5.4.1 步骤1：新主登基(某个Slave被选中成为新的Master)
选出新master的规则，剩余slave节点健康的情况下：
- redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点（数字越小优先级越高）
- 复制偏移位置offset最大的从节点// TODO
- 最小Run ID的从节点(字典顺序，ASCII码) // TODO
5.4.2 步骤2：群臣俯首(一朝天子一朝臣，换个码头重新拜)
- 执行slaveof no noe命令让选出来的从节点成为新的master，并通过slaveof命令让其他节点成为从节点
- Sentinel leader会对选举出的master执行slaveof no one操作，将其提升为master节点
- Sentinel leader向其他slave发送命令，让剩余的slave成为新的master节点的slave
5.4.3 步骤3：旧主拜服(老master回来也认怂)
- 将之前已下线的老master设置为新选出master的从节点，当老master重新上线后，它会成为新master的从节点
- Sentinel leader会让原来的master降级为slave并恢复正常工作
5.4.4 总结
上述的 failover操作均由sentinel自己独自完成，完全无需人工干预
Redis哨兵模式使用建议：
- 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
- 哨兵节点的数量应该为奇数
- 各个哨兵节点的配置应为一致
- 如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射
- 哨兵集群+主从覅u之，并不能保证数据零丢失，故障迁移需要一定的时间
尚硅谷Redis零基础到进阶，最强redis7教程，阳哥亲自带练
到此这篇redis 哨兵模式配置（redis哨兵模式搭建）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/haskellbc/33446.html