一文了解Redis中的哨兵模式
本篇文章带大家了解一下Redis中的哨兵模式，希望对大家有所帮助！
Redis 主从模式，一旦主节点发生故障，可以将从节点 升为 主节点，同时还要通知客户端更新主节点地址，这样一般是不可行的。所以，Redis 提供了 Redis Sentinel 哨兵机制 来解决这个问题。【相关推荐：Redis视频教程】
主从复制的问题
1. 主从复制的好处
- 主节点发生故障，从节点会升级为主节点
- 扩展主节点的读能力，分担主节点压力
2. 存在的问题
- 从节点升级主节点的过程需要人工干预，同时要更改客户端Redis服务地址
- 主节点写能力、存储能力受到单机限制
- 性能的影响：Redis 复制中断 后从节点会发起
psync。此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时，可能会造成毫秒或秒级的 卡顿
Sentinel 实现原理
1. 一些概念
主要功能
- 监控 ： 不断检查主从服务器是否正常运行
- 通知 ： 一旦某个节点发生故障，会通知其他节点
- 自动故障转移 ： 当主节点不能正常工作会自动进行故障转移，从其中一个从节点升级为主节点
- 配置提供者 ： 客户端不是配置单个节点，而是
Sentinel节点集合
主观下线和客观下线
一般来说，每个 Sentinel 节点会不断的 对其他 Sentinel 节点和 Redis 节点发送 PING，通过是否回复来确认是否在线
- 主观下线 ： 适用于所有主节点和从节点，如果在
down-after-milliseconds毫秒内，Sentinel没有收到目标节点的有效回复，则会判定该节点为主观下线。 - 客观下线 ： 只使用于主节点，如果主节点发生故障，
Sentinel节点会通过sentinel is-master-down-by-addr命令，向其它Sentinel节点询问对该节点的状态判断。如果超过Sentinel节点会判断主节点为客观下线。
2. 工作原理
- 每个
Sentinel以1次/s频率，向其他Sentinel节点、Redis主从节点发送PING指令。 - 如果一个实例，距离最后有效回复
PING命令超过down-after-milliseconds，这个实例被Sentinel标记为 主观下线。 - 如果一个 主服务器 被标记为主观下线，那么正在监视这个主服务器的所有
Sentinel节点，以1次/s确认此主服务器是否进入主观下线状态 - 如果超过
Sentinel节点会判断主节点为 客观下线。 - 当主服务器被标记为客观下线时，
Sentinel向下线服务器的所欲服务器发送INFO命令，会从10次/s改为1次/s。 Sentinel节点之间协商主节点状态，如果主节点处于SDOWN状态，则投票自动选出新的 主节点。将剩余的 从节点 指向 新的主节点 进行 数据复制。- 当没有足够数量的
Sentinel同意 主服务器 下线时， 主服务器 的 客观下线状态 就会被移除。当 主服务器 重新向Sentinel的PING命令返回 有效回复 时，主服务器 的 主观下线状态 就会被移除。
3. 消息丢失
Redis 采用主从复制的模式，一旦主节点挂掉，从节点正在同步的数据可能会丢失，延迟越大，丢失的越多。
Redis 提供了两个配置项来限制主库的请求处理，分别是 min-slaves-to-write 和 min-slaves-max-lag。
- min-slaves-to-write：这个配置项设置了主库能进行数据同步的最少从库数量；
- min-slaves-max-lag：这个配置项设置了主从库间进行数据复制时，从库给主库发送 ACK 消息的最大延迟（以秒为单位）。
这两个配置项组合后的要求是，主库连接的从库中至少有 N 个从库，和主库进行数据复制时的 ACK 消息延迟不能超过 T 秒，否则，主库就不会再接收客户端的请求了。
所以，Sentine 无法保证消息完全不丢失，但是也能尽量保证消息少丢失。
小结
Sentinel 解决了高可用，没有解决主节点单节点扩容的问题。
更多编程相关知识，请访问：编程入门！！
以上就是一文了解Redis中的哨兵模式的详细内容，更多请关注其它相关文章！