共计 1687 个字符，预计需要花费 5 分钟才能阅读完成。
本篇内容介绍了“怎么理解 Redis 中的哨兵模式”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
Redis 主从模式，一旦主节点发生故障，可以将从节点 升为 主节点，同时还要通知客户端更新主节点地址，这样一般是不可行的。所以，Redis 提供了 Redis Sentinel 哨兵机制 来解决这个问题。
主从复制的问题
1. 主从复制的好处
主节点发生故障，从节点会升级为主节点
扩展主节点的读能力，分担主节点压力
2. 存在的问题
从节点升级主节点的过程需要人工干预，同时要更改客户端 Redis 服务地址
主节点写能力、存储能力受到单机限制
性能的影响：Redis 复制中断 后从节点会发起 psync。此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时，可能会造成毫秒或秒级的 卡顿
Sentinel 实现原理 1. 一些概念主要功能
监控：不断检查主从服务器是否正常运行
通知：一旦某个节点发生故障，会通知其他节点
自动故障转移：当主节点不能正常工作会自动进行故障转移，从其中一个从节点升级为主节点
配置提供者：客户端不是配置单个节点，而是 Sentinel 节点集合
主观下线和客观下线
一般来说，每个 Sentinel 节点会不断的 对其他 Sentinel 节点和 Redis 节点发送 PING，通过是否回复来确认是否在线
主观下线：适用于所有主节点和从节点，如果在 down-after-milliseconds 毫秒内，Sentinel 没有收到目标节点的有效回复，则会判定该节点为主观下线。
客观下线：只使用于主节点，如果主节点发生故障，Sentinel 节点会通过 sentinel is-master-down-by-addr 命令，向其它 Sentinel 节点询问对该节点的状态判断。如果超过 quorum 个数的节点判定主节点不可达，则该 Sentinel 节点会判断主节点为客观下线。
2. 工作原理
每个 Sentinel 以 1 次 /s 频率，向其他 Sentinel 节点、Redis 主从节点发送 PING 指令。
如果一个实例，距离最后有效回复 PING 命令超过 down-after-milliseconds，这个实例被 Sentinel 标记为 主观下线。
如果一个 主服务器 被标记为主观下线，那么正在监视这个主服务器的所有 Sentinel 节点，以 1 次 /s 确认此主服务器是否进入主观下线状态
如果超过 quorum 个数的节点判定主节点不可达，则该 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 无法保证消息完全不丢失，但是也能尽量保证消息少丢失。
“怎么理解 Redis 中的哨兵模式”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！
