前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >面试必问,redis高可用原理,哨兵机制详解

面试必问,redis高可用原理,哨兵机制详解

作者头像
用户2781897
发布2020-12-15 10:15:41
5240
发布2020-12-15 10:15:41
举报
文章被收录于专栏:服务端思维

一、什么是高可用?

1、什么是高可用

redis已经实现主从复制了,即使挂了一台或者服务硬盘坏掉,数据存在同步备份。那它还不是高可用吗?当然!不是~

高可用的定义一般有以下两个解释:

解释1:它与被认为是不间断操作的容错技术有所不同。是目前企业防止核心系统因故障而无法工作的最有效保护手段

解释2:高可用一般指服务的冗余,一个服务挂了,可以自动切换到另外一个服务上,不影响客户体验。

主要就是当我们服务存在异常的时候,可以自动进行容错或者抵抗异常,从而达到不影响到用户正常使用的一种技术

2、主从复制是否高可用分析

1,主从复制,若主节点出现问题,则不能提供服务,需要人工修改配置将从变主

A,主节点(master)故障,从节点slave-1端执行 slaveof no one后变成新主节点;

B,其它的节点成为新主节点的从节点,并从新节点复制数据;

C,需要人工干预,无法实现高可用。

2,主从复制主节点的写能力单机,能力有限

3,单机节点的存储能力也有限

因此,主从复制并不能满足我们高可用的要求。

二、什么是哨兵机制

Sentinel(哨兵)是Redis 的高可用性解决方案:由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器进入下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器。

原理:当主节点出现故障时,由Redis Sentinel自动完成故障发现和转移,并通知应用方,实现高可用性

三、redis哨兵机制的实现

1、哨兵主要任务

哨兵主要有三个定时监控任务完成对各节点的发现和监控。

任务1:每个哨兵节点每10 秒会向主节点和从节点发送info 命令获取最拓扑结构图,哨兵配置时只要配置对主节点的监控即可,通过向主节点发送info,获取从节点的信息,并当有新的从节点加入时可以马上感知到

任务2,每个哨兵节点每隔2 秒会向redis 数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息,同时每个哨兵节点也会订阅该频道,来了解其它哨兵节点的信息及对主节点的判断,其实就是通过消息publish 和subscribe 来完成的;

任务3,每隔1 秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping 命令做一次心跳检测,这个也是哨兵用来判断节点是否正常的重要依据

2、哨兵发现服务下线

哨兵主观下线

主观下线:刚我知道哨兵节点每隔 1 秒对主节点和从节点、其它哨兵节点发送 ping 做心跳检测,当这些心跳检测时间超过 down-after-milliseconds 时,哨兵节点则认为该节点 错误或下线,这叫主观下线;当然这但不代表这个master真的不能用(有可能网络波动导致该哨兵与服务连接异常),所以主观下线是不可靠的,可能存在误判

哨兵客观下线

客观下线:当主观下线的节点是主节点时,此时该哨兵3 节点会通过指令sentinelis-masterdown-by-addr 寻求其它哨兵节点对主节点的判断,当超过quorum(法定人数)个数,此时哨兵节点则认为该主节点确实有问题,这样就客观下线了,大部分哨兵节点都同意下线操作,也就说是客观下线

一般来说客观下线满足大多数原则,因此是可靠的判断。

3、领导者哨兵选举流程

a,每个在线的哨兵节点都可以成为领导者,当它确认(比如哨兵3)主节点下线时,会向其它哨兵发is-master-down-by-addr 命令,征求判断并要求将自己设置为领导者,由领导者处理故障转移; b,当其它哨兵收到此命令时,可以同意或者拒绝它成为领导者; c,如果哨兵3 发现自己在选举的票数大于等num(sentinels)/2+1 时,将成为领导者,如果没有超过,继续选举…………

4、服务故障处理

A、由Sentinel节点定期监控发现主节点是否出现了故障

sentinel会向master发送心跳PING来确认master是否存活,如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息,那么这个sentinel会主观地(单方面地)认为这个master已经不可用了

B,当主节点出现故障,此时3 个Sentinel 节点共同选举了Sentinel3 节点为领导,负载处理主节点的故障转移,

C,由Sentinel3领导者节点执行故障转移,过程和主从复制一样,但是自动执行

最后集群架构如下

5,故障转移选举节点选择

主要流程如下

A,过滤掉不健康的(下线或断线),没有回复过哨兵 ping 响应的从节点

B,选择 slave-priority 从节点优先级最高(redis.conf)

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

— 本文结束 —

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-12-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 服务端思维 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1、什么是高可用
  • 2、主从复制是否高可用分析
  • 二、什么是哨兵机制
  • 三、redis哨兵机制的实现
    • 1、哨兵主要任务
      • 2、哨兵发现服务下线
        • 3、领导者哨兵选举流程
          • 4、服务故障处理
            • 5,故障转移选举节点选择
            相关产品与服务
            云数据库 Redis®
            腾讯云数据库 Redis®(TencentDB for Redis®)是腾讯云打造的兼容 Redis 协议的缓存和存储服务。丰富的数据结构能帮助您完成不同类型的业务场景开发。支持主从热备,提供自动容灾切换、数据备份、故障迁移、实例监控、在线扩容、数据回档等全套的数据库服务。
            领券
            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档