一文了解Redis中的哨兵模式

本篇文章带大家了解一下Redis中的哨兵模式,希望对大家有所帮助!

一文了解Redis中的哨兵模式

Redis 主从模式,一旦主节点发生故障,可以将从节点 升为 主节点,同时还要通知客户端更新主节点地址,这样一般是不可行的。所以,Redis 提供了 Redis Sentinel 哨兵机制 来解决这个问题。【相关推荐:Redis视频教程】

主从复制的问题

1.png

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. 工作原理

2.png

  • 每个 Sentinel1次/s 频率,向其他 Sentinel 节点、Redis 主从节点发送 PING 指令。
  • 如果一个实例,距离最后有效回复 PING 命令超过 down-after-milliseconds,这个实例被 Sentinel 标记为 主观下线
  • 如果一个 主服务器 被标记为主观下线,那么正在监视这个主服务器的所有 Sentinel 节点,以 1次/s 确认此主服务器是否进入主观下线状态
  • 如果超过 个数的节点判定主节点不可达,则该 Sentinel 节点会判断主节点为 客观下线
  • 当主服务器被标记为客观下线时,Sentinel 向下线服务器的所欲服务器发送 INFO 命令,会从10次/s 改为 1次/s
  • Sentinel 节点之间协商主节点状态,如果主节点处于 SDOWN 状态,则投票自动选出新的 主节点。将剩余的 从节点 指向 新的主节点 进行 数据复制
  • 当没有足够数量的 Sentinel 同意 主服务器 下线时, 主服务器客观下线状态 就会被移除。当 主服务器 重新向 SentinelPING 命令返回 有效回复 时,主服务器主观下线状态 就会被移除。

3. 消息丢失

Redis 采用主从复制的模式,一旦主节点挂掉,从节点正在同步的数据可能会丢失,延迟越大,丢失的越多。

Redis 提供了两个配置项来限制主库的请求处理,分别是 min-slaves-to-writemin-slaves-max-lag

  • min-slaves-to-write:这个配置项设置了主库能进行数据同步的最少从库数量;
  • min-slaves-max-lag:这个配置项设置了主从库间进行数据复制时,从库给主库发送 ACK 消息的最大延迟(以秒为单位)。

这两个配置项组合后的要求是,主库连接的从库中至少有 N 个从库,和主库进行数据复制时的 ACK 消息延迟不能超过 T 秒,否则,主库就不会再接收客户端的请求了

所以,Sentine 无法保证消息完全不丢失,但是也能尽量保证消息少丢失。

小结

Sentinel 解决了高可用,没有解决主节点单节点扩容的问题。

更多编程相关知识,请访问:编程入门!!

以上就是一文了解Redis中的哨兵模式的详细内容,更多请关注https://www.sxiaw.com/其它相关文章!