Redis的哨兵机制

为什么需要哨兵机制

redis的主从复制主要用于实现数据的冗余备份和读负担,并不是为了提供高可用性,因此系统高可用方面,单纯的主从架构无法很好的保证整个系统高可用,比如说

  • 需要人工介入:当redis一个主节点宕机时,需要人工介入进行主节点的切换,当主节点发送故障时,主从复制无法自动进行主节点的切换,需要管理员进行手动干预,修改配置将一个从节点提升为新的主节点。这增加了人工操作的复杂性和潜在的延迟。

  • 主节点写能力有限:主结点的写能力受限于当个节点,在主从复制中,所有写操作都必须发送给主结点处理,然后再同步到从结点。这导致主节点成为写入瓶颈,其写能力受限于单个结点的硬件和性能。如果负载过大,主节点的响应时间可能会增加,影响整体性能。

  • 单机节点存储能力有限:存储能力受限于主节点的容量。在主从复制中,所有数据都存储在主节点上,从节点仅用于提供读服务。这限制了整个系统的存储能力,因为主节点的存储容量有限。如果数据量增长过快或存储需求增加,主节点的存储容量可能会成为瓶颈。

  • 因此通常是使用Redis哨兵机制或Redis集群模式来提高整个系统的可用性、扩展性和负载均衡能力

哨兵机制的原理

Redis的哨兵机制是通过在独立的哨兵节点上运行特定的哨兵进程来实现的。这些哨兵进程监控主从节点的状态,并在发现故障时自动完成故障发现和转移,并通知应用方,实现高可用性

哨兵选举

在启动时,每个哨兵会执行选举过程,其中一个哨兵被选为领导者,负责协调其他哨兵节点

选举过程:

  • 每个在线的哨兵节点都可以成为领导者,每个哨兵节点会向其他哨兵发is-master-down-by-addr命令,征求判断并要求将自己设置为领导者

  • 当其他哨兵接受到此命令时,可以同意或者拒接他成为领导者

  • 如果哨兵发现自己在选举的票数大于等于num(sentinels)/2+1时,将成为领导者,如果没有超过,继续选举。

监控主从节点

哨兵节点通过发送命令周期性地检查主从节点的健康状态,包括主节点是否在线,从节点是否同步等,如果哨兵节点发现主节点不可用,他会触发一次故障转移(大多数节点觉得不可用)

故障转移

一旦主节点被判定为不可用,哨兵节点会执行故障转移操作。他会从当前的从节点选出一个新的主节点,并将其他的从结点切换到新的主节点。这样,系统可以继续提高服务而无需人工介入

故障转移过程

  • 由Sentinel节点定期监控发现主节点是否出现了故障:sentinel会向master发送心跳PING来确认master是否存活,如果master在一定时间范围内不回应PONG或者是回复了一个错误消息,那么整个sentinel会主观地(单方面)认为这个master已经不可用了

  • 确定主节点:

    1. 过滤掉不监控的(下线或断线),没有回复过哨兵ping响应的从节点

    2. 选择从节点优先级最高的

    3. 选择复制偏移量最大,此指复制最完整的从节点

    当主节点出现故障,由领导者负责处理主节点的故障转移

客户端重定向

哨兵节点会通知客户端新的主节点的位置,使其能够与新的主节点建立连接并发送请求,这确保了客户端可以无缝切换到新的主节点,继续进行操作。

此外,哨兵节点还负责监控从节点的状态,如果从节点出现故障,哨兵节点可以将其下线,并在从节点恢复正常后将其加入集群。

客观下线

当主观下线的节点是主节点时,此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其他哨兵节点对主节点的判断,当超过选举个数,此时哨兵节点则认为该主节点确实有问题,这样就可以客观下线了,大部分哨兵节点都同意下线操作,也就是客观下线。

  • 14
    点赞
  • 17
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值