【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?--主从切换方案

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介: 【5月更文挑战第16天】该方案提出了解决Redis缓存穿透、击穿和雪崩问题的策略。通过使用两个或多个互为备份的Redis集群,确保在单个集群故障时,另一个可以接管。在故障发生时,业务会与备用集群保持心跳检测,并根据业务重要性分批转移流量,逐步增加对备用集群的依赖,同时监控系统稳定性。对于成本敏感的小型公司,可以采用低成本的单机或小规模自建Redis备份。此方案强调渐进式流量转移,以保护系统免受突然压力冲击。

亮点方案

不管是换成你穿透、击穿还是雪崩,归根结底都是请求都落到了数据库上。除了这三个异常,Redis本身也可能崩溃,又或者因为网络问题连不上这个集群。集群互为备份这个亮点方案可以很好的解决这个问题。

很多大厂会用一些异地多活的方案,就是使用两个 Redis 集群,然后两个集群之间要保持数据同步。那么其中一个 Redis 集群崩溃的时候,就可以用另外一个 Redis 集群。

但是,这个方案太高端了,不在大厂的话很难接触到。所以我给你准备一个比较低端但是更加容易落地的方案。这个方案的思路还是用两个或者多个 Redis 集群,但是你不会让这些集群之间保持数据同步。比如说你可以在两个云服务厂商上购买两个不同的 Redis 服务,然后尽可能让核心业务访问不同的集群。
2024-05-18-23-12-14-image.png

假设说我有两个业务,那么我准备两个 Redis 集群,业务 1 主要用集群 1,集群 2 作为备份。业务 2 主要使用集群 2,集群 1 作为备份。

具体思路是这样的:

第一,业务 1 会和集群 1 保持心跳。当发现连不上 Redis 之后,就可以执行容错方案,这个时候业务 1 会保持和集群 1 的心跳。

第二,触发容错之后,业务 1 根据流量价值分成两部分。对于非核心业务来说,直接触发熔断,不会查询集群 2,也不会查询数据库,这是舍小保大。对于核心业务来说,按照预先设置的流量比例,查询集群 2,并回查数据库,其余请求一样熔断。如果当前流量比例查询集群 2 没有引起任何的问题,数据库也没有问题,那么就增大流量比例。

第三,当集群 1 重新恢复心跳之后,业务 1 还是逐步把集群 2 上的流量转发到集群 1 上。
2024-05-18-23-12-58-image.png

你可以进一步总结这个思路的要点,就是渐进式

在触发容错之后,没有立刻把全部流量转发到集群 2 上,是因为担心集群 2 会撑不住,所以要逐步转发流量,每次转发之后发现没问题就可以调大比例。转发回集群 1 也是这样,因为和集群 1 刚恢复通信的时候,集群 1 上面什么数据都没有,而这个时候集群 2 还能用,所以不着急立刻转发回来,先小规模流量重建集群 1 上的数据。

那么为什么互为备份可行呢?因为正常 Redis 集群都有很大的余量,在遇到问题的时候互为备份顶一下就可以。当技术人员发现问题之后,会紧急采购新的 Redis 服务,或者部署新的集群接替集群 1。所以集群 2 大概率会在高负载状态下运行一段时间。

如果你面试的是比较小型的公司,对成本比较敏感,你就可以补充一个变种,关键词是凑合用便宜货。

如果觉得两个 Redis 集群服务太贵,那么也有一个低成本方案,公司可以自己部署一个小规模的 Redis 集群,甚至单机 Redis 作为所有业务的备份。这个 Redis 集群不要求高可用,对它的唯一要求就是撑住我线上集群的核心流量一段时间就可以。毕竟,不管这个备份集群有多差,都比完全没有要好。
2024-05-18-23-13-46-image.png

这里还有一些细节问题。

第一个是最开始按多少比例转发到集群 2 上比较合适,答案是这个初始流量的大小就是你业务数据库能撑住的流量大小。因为一开始转发到集群 2 上的流量,肯定都是缓存未命中的,也就是要回查数据库,所以数据库决定了这个初始流量。

第二个问题是后续流量要怎么放开。答案是你可以自由选择,按照比例增长、线性增长都可以。但是原则是要保守,因为你万一把集群 2 弄崩溃了,业务损失就更大了。

第三个问题就是怎么判定 Redis 已经崩溃了,或者恢复过来了?这个问题你在微服务部分已经多次遇到了,思路都是一样的,这里我就不重复了。

相关实践学习
基于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
目录
相关文章
|
13天前
|
小程序 数据可视化 Java
Java+后端Spring boot 开发的全套UWB定位方案,0.1米高精度定位系统源码
UWB定位系统由硬件定位设备、定位引擎和应用软件组成。该定位系统应用软件支持PC端和移动端访问,并提供位置实时显示、历史轨迹回放、人员考勤、电子围栏、行为分析、智能巡检等功能。定位精度高达10cm,同时具备高动态、高容量、低功耗的优点。应用场景包括:隧道、化工、工厂、煤矿、工地、电厂、养老、展馆、整车、机房、机场等。
37 8
|
21天前
|
缓存 监控 NoSQL
redis 缓存穿透 击穿 雪崩 的原因及解决方法
redis 缓存穿透 击穿 雪崩 的原因及解决方法
|
12天前
|
存储 缓存 NoSQL
应对危机如何处理缓存击穿风险
【6月更文挑战第9天】本文介绍如何应对缓存穿透,这可以通过限制IP访问次数、预热缓存、设置空值以及使用布隆过滤器来过滤非法请求。布隆过滤器占用空间小,有误判率但速度快,适用于广告投放、内容推荐和数据库查询等场景。其优点包括低时间复杂度、并行运算和节省空间,但存在误判、无法存储元素及删除操作的局限性。
30 4
应对危机如何处理缓存击穿风险
|
1月前
|
NoSQL Redis 缓存
【后端面经】【缓存】36|Redis 单线程:为什么 Redis 用单线程而 Memcached 用多线程?
【5月更文挑战第17天】Redis常被称为单线程,但实际上其在处理命令时采用单线程,但在6.0后IO变为多线程。持久化和数据同步等任务由额外线程处理,因此严格来说Redis是多线程的。面试时需理解Redis的IO模型,如epoll和Reactor模式,以及其内存操作带来的高性能。Redis使用epoll进行高效文件描述符管理,实现高性能的网络IO。在讨论Redis与Memcached的线程模型差异时,应强调Redis的单线程模型如何通过内存操作和高效IO实现高性能。
47 7
【后端面经】【缓存】36|Redis 单线程:为什么 Redis 用单线程而 Memcached 用多线程?
|
4天前
|
安全 Java 应用服务中间件
详细介绍几种处理后端跨域问题的方案
详细介绍几种处理后端跨域问题的方案
|
1月前
|
缓存 NoSQL Redis
【后端面经】【缓存】36|Redis 单线程:为什么 Redis 用单线程而 Memcached 用多线程?--epoll调用和中断
【5月更文挑战第18天】`epoll`包含红黑树和就绪列表,用于高效管理文件描述符。关键系统调用有3个:`epoll_create()`创建epoll结构,`epoll_ctl()`添加/删除/修改文件描述符,`epoll_wait()`获取就绪文件描述符。`epoll_wait()`可设置超时时间(-1阻塞,0立即返回,正数等待指定时间)。当文件描述符满足条件(如数据到达)时,通过中断机制(如网卡或时钟中断)更新就绪列表,唤醒等待的进程。
49 6
|
1月前
|
缓存 NoSQL 中间件
【后端面经】【缓存】36|Redis 单线程:为什么 Redis 用单线程而 Memcached 用多线程?epoll、poll和select + Reactor模式
【5月更文挑战第19天】`epoll`、`poll`和`select`是Linux下多路复用IO的三种方式。`select`需要主动调用检查文件描述符,而`epoll`能实现回调,即使不调用`epoll_wait`也能处理就绪事件。`poll`与`select`类似,但支持更多文件描述符。面试时,重点讲解`epoll`的高效性和`Reactor`模式,该模式包括一个分发器和多个处理器,用于处理连接和读写事件。Redis采用单线程模型结合`epoll`的Reactor模式,确保高性能。在Redis 6.0后引入多线程,但基本原理保持不变。
40 2
|
30天前
|
缓存 NoSQL Redis
【后端面经】【缓存】36|Redis 单线程:为什么 Redis 用单线程而 Memcached 用多线程?-- Redis多线程
【5月更文挑战第21天】Redis启用多线程后,主线程负责接收事件和命令执行,IO线程处理读写数据。请求处理流程中,主线程接收客户端请求,IO线程读取并解析命令,主线程执行后写回响应。业界普遍认为,除非必要,否则不建议启用多线程模式,因单线程性能已能满足多数需求。公司实际场景中,启用多线程使QPS提升约50%,或选择使用Redis Cluster以提升性能和可用性。
33 0
|
1月前
|
NoSQL Redis 数据库
【后端面经】【缓存】36|Redis 单线程:为什么 Redis 用单线程而 Memcached 用多线程?-- Memcache + Redis 多线程
【5月更文挑战第20天】Redis采用单线程模式以避免上下文切换和资源竞争,简化调试,且其性能瓶颈在于网络IO和内存,而非多线程。相比之下,Memcache使用多线程能更好地利用多核CPU,但伴随上下文切换和锁管理的开销。尽管Redis单线程性能不俗,6.0版本引入多线程以提升高并发下的IO处理能力。启用多线程后,Redis结合Reactor和epoll实现并发处理,提高系统性能。
45 0
|
7天前
|
存储 缓存 NoSQL
Redis缓存的运用
缓存预热就是系统上线后,将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请 求的时候,先查询数据库,然后再将数据缓存的问题!用户直接查询事先被预热的缓存数据!
13 1