超全面Redis分布式高可用方案:哨兵机制

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
简介: 开发工作中对于分布式缓存高可用方案(搭建 Redis 缓存高可用方案),Redis 主从架构下是如何保证高可用的呢?

微信图片_20220609110241.jpg

开发工作中对于分布式缓存高可用方案(搭建 Redis 缓存高可用方案),Redis 主从架构下是如何保证高可用的呢?


我们知道 Redis Sentinel 是一个分布式系统,为 Redis 提供高可用性解决方案。那 Redis 服务部署的哨兵模式主要原理是什么,又解决了什么问题呢,于是利用时间将相关问题做了整理,相信看完这篇文章,你也可以去给别人做技术分享了。O(∩_∩)O 哈哈~


0. 问题铺垫


在讨论哨兵模式之前,我们先来看一个应用问题:Redis服务主机宕机


实际使用过程中,会出现master宕机的情况(这样会导致没有写服务,只有读服务)。那我们要保证服务的可用,就需要从其他salve节点中选取一个来作为master节点,来继续提供服务能力。


那主要的动作抽象下:


  • 将宕机的master下线


  • 找一个slave作为master


  • 通知所有的slave连接新的master


  • 全量数据或者部分数据同步

其中存在几个问题:


  • 谁来确认master宕机?(假如仅仅是网络抖动了一下,就把我宕掉么?)
  • 如何从slave中找一个master代替,谁来找?怎么找?有什么依据?
  • 修改配置后,原始的主恢复了怎么办?

其实引入哨兵机制,就可以很好的解决上述问题。

微信图片_20220609110244.png

哨兵-Redis集群

1. 什么是哨兵?


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


总结一下哨兵的作用:


  • 集群监控


   不断的检查master和slave是否正常运行(master存活检测、master与slave运行情况检测)


  • 消息通知


   当被监控的服务器出现问题时,向其他哨兵、客户端发送通知


  • 自动故障转移


   断开故障master与slave的连接,选取一个slave作为新master,将其他slave连接到新的master并告知客户端新的服务器地址。


注意:哨兵也是一台Redis服务器,只是不提供数据服务;通常哨兵配置的数量为单数。


2. 哨兵的工作原理


下面主要针对哨兵在进行故障转移过程中经历的三个阶段分别进行阐述。


2.1. 集群监控


step1:哨兵1连接到Redis集群


  • 发送info命令到master,并建立cmd连接;


  • 哨兵端保存哨兵状态(SentinelStatus),保存所有哨兵状态,主节点和从节点的信息;master端会记录 redis 实例的信息(SentinelRedisInstance);


  • 哨兵根据master中获取的每个slave信息,去连接每个slave,发送同样也是info命令。

微信图片_20220609110247.png

集群监控


step2:哨兵2加入进来后


  • 同样会发送info命令到master节点,并建立cmd连接;


  • 发现master中存在其他哨兵节点的信息,哨兵2中保存哨兵信息(区别与哨兵1的是它保存了哨兵1和哨兵2的2个哨兵节点信息);


  • 为了每个哨兵的信息都一致它们之间建立了一个发布订阅。为了哨兵之间的信息长期对称它们之间也会互发 ping 命令。

微信图片_20220609110249.png

集群监控


step3:哨兵3加入后


  • 同样进行哨兵1、2的动作,会发送info命令到master节点,并建立cmd连接;


  • 为了保证哨兵1-哨兵2之间的信息是同步的,建立了一个发布订阅的一个队列(可以互发ping命令)

微信图片_20220609110252.png

集群监控


小小总结一下:


  • Sentinel会向master、slave以及其他Sentinel获取状态;


  • Sentinel之间会组建“对应频道”,大家一起发布信息、订阅信息、收信息、同步信息等。


2.2. 消息通知


1)Sentinel节点会通过master/slave 节点建立的cmd连接获取其工作状态


2)Sentinel收到反馈结果之后,会在哨兵内部进行信息的互通


微信图片_20220609110255.png

消息通知

2.3. 故障转移


关于故障转移,严格来讲可划分两个步骤:故障判定故障转移


Q1:如何判断一个节点出现故障?


  • 哨兵会一直给主节点发送 publish sentinel:hello


直到主节点故障,哨兵报出 sdown,同时此哨兵还会向其他哨兵发布消息说这个主节点挂了。发送的指令是 sentinel is-master-down-by-address-port。


  • 其余的哨兵接收到指令后,主节点挂了吗?让我去看看到底挂没挂。发送的信息也是 hello。


其余的哨兵也会发送他们收到的信息并且发送指令 sentinel is-master-down-by-address-port 到自己的内网,确认一下第一个发送 sentinel is-master-down-by-address-port 的哨兵说你说的对,这个家伙确实挂了。


  • 当所有人都认为主节点挂了后就会修改其状态为 odown。


当一个哨兵认为主节点挂了标记的是 sdown,当半数哨兵都认为挂了其标记的状态是 odown。


一个哨兵认为master节点挂了称为主观下线(sdown),超半数哨兵认为master节点挂了则称为客观下线(odown)。


微信图片_20220609110258.png

Q2:如何进行故障转移?


1)首先,哨兵选举出哨兵Leader去处理故障转移


此时选举方式应用的是Raft协议,这个之前有过介绍,感兴趣的同学可以移步了解:一致性算法Raft 简易入门


2)其次,哨兵Leader从所有的slave节点找出一个作为master节点


主要的规则:


  • 选择在线的节点,pass掉已下线的节点;


  • 选择响应速度快的,pass掉响应慢的节点


  • 选择与原master断开时间短的,pass掉断开时间较长的;


假如以上优先级均一致,会考虑其他优先原则:


  • 偏移量较大


假如说 slave1 的 offset 为 50,slave2 偏移量为 55,则哨兵就会选择 slave2 为新的主节点。


  • runid偏大的


这点类似于职场中的论资排辈,也就说根据 runid 的创建时间来判断,时间早的先上位。



3)数据转移


  • 新master上任:Sentinel向新的master发送slaveof no one


  • 其他slave周知:向其他slave发送slaveof 新master IP端口


3. 总结


Redis 主从复制的作用中有这么一句话“主从复制是高可用的基石”,那实现高可用必不可少的就是哨兵和集群。


3.1 Sentinel的作用


  • 集群监控


不断的检查master和slave是否正常运行(master存活检测、master与slave运行情况检测)


  • 消息通知


当被监控的服务器出现问题时,向其他哨兵、客户端发送通知


  • 自动故障转移


断开故障master与slave的连接,选取一个slave作为新master,将其他slave连接到新的master并告知客户端新的服务器地址。


3.2 Sentinel的工作方式


  • 每个Sentinel以每秒钟一次的频率向它所知的Master,Slave以及其他 Sentinel 实例发送一个 PING 命令


  • 如果一个实例(Instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel 标记为主观下线。


若 Master 重新向 Sentinel 的 PING 命令返回有效回复, Master 的主观下线状态就会被移除。


  • 如果一个Master被标记为主观下线,则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。


  • 当有足够数量的 Sentinel(>=配置文件指定的值)在指定的时间范围内确认Master的确进入了主观下线状态, 则Master会被标记为客观下线


若没有足够数量的 Sentinel 同意 Master 已经下线, Master 的客观下线状态就会被移除。


  • 在一般情况下, 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master,Slave发送 INFO 命令


  • 当Master被 Sentinel 标记为客观下线时,Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
打赏
0
0
0
0
677
分享
相关文章
|
12天前
|
【📕分布式锁通关指南 02】基于Redis实现的分布式锁
本文介绍了从单机锁到分布式锁的演变,重点探讨了使用Redis实现分布式锁的方法。分布式锁用于控制分布式系统中多个实例对共享资源的同步访问,需满足互斥性、可重入性、锁超时防死锁和锁释放正确防误删等特性。文章通过具体示例展示了如何利用Redis的`setnx`命令实现加锁,并分析了简化版分布式锁存在的问题,如锁超时和误删。为了解决这些问题,文中提出了设置锁过期时间和在解锁前验证持有锁的线程身份的优化方案。最后指出,尽管当前设计已解决部分问题,但仍存在进一步优化的空间,将在后续章节继续探讨。
449 131
【📕分布式锁通关指南 02】基于Redis实现的分布式锁
|
15天前
|
Springboot使用Redis实现分布式锁
通过这些步骤和示例,您可以系统地了解如何在Spring Boot中使用Redis实现分布式锁,并在实际项目中应用。希望这些内容对您的学习和工作有所帮助。
140 83
【📕分布式锁通关指南 03】通过Lua脚本保证redis操作的原子性
本文介绍了如何通过Lua脚本在Redis中实现分布式锁的原子性操作,避免并发问题。首先讲解了Lua脚本的基本概念及其在Redis中的使用方法,包括通过`eval`指令执行Lua脚本和通过`script load`指令缓存脚本。接着详细展示了如何用Lua脚本实现加锁、解锁及可重入锁的功能,确保同一线程可以多次获取锁而不发生死锁。最后,通过代码示例演示了如何在实际业务中调用这些Lua脚本,确保锁操作的原子性和安全性。
37 6
【📕分布式锁通关指南 03】通过Lua脚本保证redis操作的原子性
Redis,分布式缓存演化之路
本文介绍了基于Redis的分布式缓存演化,探讨了分布式锁和缓存一致性问题及其解决方案。首先分析了本地缓存和分布式缓存的区别与优劣,接着深入讲解了分布式远程缓存带来的并发、缓存失效(穿透、雪崩、击穿)等问题及应对策略。文章还详细描述了如何使用Redis实现分布式锁,确保高并发场景下的数据一致性和系统稳定性。最后,通过双写模式和失效模式讨论了缓存一致性问题,并提出了多种解决方案,如引入Canal中间件等。希望这些内容能为读者在设计分布式缓存系统时提供有价值的参考。感谢您的阅读!
113 6
Redis,分布式缓存演化之路
|
4天前
|
【📕分布式锁通关指南 04】redis分布式锁的细节问题以及RedLock算法原理
本文深入探讨了基于Redis实现分布式锁时遇到的细节问题及解决方案。首先,针对锁续期问题,提出了通过独立服务、获取锁进程自己续期和异步线程三种方式,并详细介绍了如何利用Lua脚本和守护线程实现自动续期。接着,解决了锁阻塞问题,引入了带超时时间的`tryLock`机制,确保在高并发场景下不会无限等待锁。最后,作为知识扩展,讲解了RedLock算法原理及其在实际业务中的局限性。文章强调,在并发量不高的场景中手写分布式锁可行,但推荐使用更成熟的Redisson框架来实现分布式锁,以保证系统的稳定性和可靠性。
17 0
为什么分布式一定要有redis?
1、为什么使用redis 分析:博主觉得在项目中使用redis,主要是从两个角度去考虑:性能和并发。当然,redis还具备可以做分布式锁等其他功能,但是如果只是为了分布式锁这些其他功能,完全还有其他中间件(如zookpeer等)代替,并不是非要使用redis。
1384 0
解决Redis缓存数据类型丢失问题
解决Redis缓存数据类型丢失问题
196 85
云端问道21期方案教学-应对高并发,利用云数据库 Tair(兼容 Redis®*)缓存实现极速响应
云端问道21期方案教学-应对高并发,利用云数据库 Tair(兼容 Redis®*)缓存实现极速响应
云端问道21期实操教学-应对高并发,利用云数据库 Tair(兼容 Redis®)缓存实现极速响应
本文介绍了如何通过云端问道21期实操教学,利用云数据库 Tair(兼容 Redis®)缓存实现高并发场景下的极速响应。主要内容分为四部分:方案概览、部署准备、一键部署和完成及清理。方案概览中,展示了如何使用 Redis 提升业务性能,降低响应时间;部署准备介绍了账号注册与充值步骤;一键部署详细讲解了创建 ECS、RDS 和 Redis 实例的过程;最后,通过对比测试验证了 Redis 缓存的有效性,并指导用户清理资源以避免额外费用。
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等