本篇内容介绍了“怎么理解redis中的哨兵模式”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
成都创新互联专注于网站建设|成都网站维护|优化|托管以及网络推广，积累了大量的网站设计与制作经验，为许多企业提供了网站定制设计服务，案例作品覆盖成都除甲醛等行业。能根据企业所处的行业与销售的产品，结合品牌形象的塑造，量身定制品质网站。
Redis 主从模式，一旦主节点发生故障，可以将从节点 升为 主节点，同时还要通知客户端更新主节点地址，这样一般是不可行的。所以，Redis 提供了 Redis Sentinel 哨兵机制来解决这个问题。
主节点发生故障，从节点会升级为主节点
扩展主节点的读能力，分担主节点压力
从节点升级主节点的过程需要人工干预，同时要更改客户端Redis服务地址
主节点写能力、存储能力受到单机限制
性能的影响：Redis 复制中断 后从节点会发起 psync。此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时，可能会造成毫秒或秒级的 卡顿
监控 ：不断检查主从服务器是否正常运行
通知 ：一旦某个节点发生故障，会通知其他节点
自动故障转移 ：当主节点不能正常工作会自动进行故障转移，从其中一个从节点升级为主节点
配置提供者 ：客户端不是配置单个节点，而是 Sentinel 节点集合
一般来说，每个 Sentinel 节点会不断的 对其他 Sentinel 节点和 Redis 节点发送 PING，通过是否回复来确认是否在线
主观下线 ：适用于所有主节点和从节点，如果在 down-after-milliseconds 毫秒内，Sentinel 没有收到目标节点的有效回复，则会判定该节点为主观下线。
客观下线 ：只使用于主节点，如果主节点发生故障，Sentinel 节点会通过 sentinel is-master-down-by-addr 命令，向其它 Sentinel 节点询问对该节点的状态判断。如果超过 Sentinel 节点会判断主节点为客观下线。
每个 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 命令返回 有效回复时，主服务器的 主观下线状态就会被移除。
Redis 采用主从复制的模式，一旦主节点挂掉，从节点正在同步的数据可能会丢失，延迟越大，丢失的越多。
Redis 提供了两个配置项来限制主库的请求处理，分别是 min-slaves-to-write 和 min-slaves-max-lag。
min-slaves-to-write：这个配置项设置了主库能进行数据同步的最少从库数量；
min-slaves-max-lag：这个配置项设置了主从库间进行数据复制时，从库给主库发送 ACK 消息的最大延迟（以秒为单位）。
这两个配置项组合后的要求是，主库连接的从库中至少有 N 个从库，和主库进行数据复制时的 ACK 消息延迟不能超过 T 秒，否则，主库就不会再接收客户端的请求了。
所以，Sentine 无法保证消息完全不丢失，但是也能尽量保证消息少丢失。
“怎么理解Redis中的哨兵模式”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！
