Redis 五大经典业务问题

时间:2024-01-10 00:59:11 标签:  自创  redis  数据库  缓存  

一 缓存穿透

缓存穿透是指当请求的数据既不在缓存中也不存在于数据库中时,请求会直接穿透缓存层,到达数据库层。这通常是由于恶意攻击或者程序错误造成的,比如攻击者故意请求不存在的大量数据,导致缓存不命中,所有的请求都会落到数据库上,从而可能对数据库造成巨大的压力,影响其性能甚至导致崩溃通常是 thread_running 飙高。

解决方案:
  1. 布隆过滤器(Bloom Filter):
    布隆过滤器是一种数据结构,可以用来检测一个元素是否在一个集合中。在请求到达缓存之前,先通过布隆过滤器进行检查,如果布隆过滤器判断数据不存在,则直接返回错误响应,避免对数据库的访问。

  2. 缓存空结果:
    当查询数据库后发现数据不存在时,可以将这个"空结果"也缓存起来,并设置一个较短的过期时间。这样当再次请求相同的数据时,可以直接从缓存中获取到"空结果",避免对数据库的访问。需要注意的是,这种方法可能会导致缓存被大量无用的空结果填满,所以需要合理设置过期时间。

  3. 限制请求:
    对于异常频繁的访问行为,可以采取限流、封禁IP等手段进行限制。例如,可以对每个用户的访问频率、请求的速度等进行限制,超过限制则暂时封禁其请求。

  4. 接口鉴权:
    在接口层做好身份验证和参数校验,不允许非法请求或者格式不正确的请求访问数据库。

  5. 数据库建立合理索引:
    对于一些必须要访问数据库的场景,确保数据库有好的查询性能,可以通过建立合理的索引来提高查询效率。

  6. 二级缓存:
    使用本地缓存作为一级缓存,Redis作为二级缓存。当本地缓存不命中时再查询Redis,如果Redis也不命中,最后才去查询数据库。这样可以减少直接对Redis的查询请求,降低Redis的压力。

  7. 前端控制:
    在前端应用中加强校验,比如表单校验、输入内容的合法性检查等,避免发送无效请求到后端。

二 缓存雪崩

缓存雪崩是指在缓存系统中,由于大量缓存数据在同一时间过期,或者缓存服务宕机,导致所有的请求都直接落到数据库上,造成数据库瞬间承受巨大的访问压力,从而变得不稳定甚至崩溃的现象。这类似于雪崩一样,一旦发生就会导致连锁反应,导致整个系统的性能急剧下降。

解决方案:
  1. 缓存数据的过期时间随机化:
    设置缓存数据的过期时间时,不要让大量的缓存数据在同一时间点过期。可以对过期时间加上一个随机值,使得缓存数据的过期时间分散开来,防止在同一时刻大面积缓存失效。

  2. 使用持久化:
    如果缓存服务支持持久化,比如Redis的RDB和AOF,要确保开启并合理配置这些功能。这样,即使缓存服务重启,也能从持久化的数据中恢复,减少缓存雪崩的风险。

  3. 设置热点数据永不过期:
    对于一些热点数据,可以设置为永不过期,或者采用手动更新缓存的策略,避免这些热点数据集体过期。

  4. 使用多级缓存策略:
    可以使用本地缓存(如Ehcache)和分布式缓存(如Redis)结合的多级缓存策略,即使分布式缓存不可用,本地缓存仍然可以提供服务,减少对数据库的直接压力。

  5. 提升缓存服务的高可用性:
    使用主从复制、哨兵机制、集群等高可用方案来确保缓存服务的稳定性。即便单个节点出现故障,也能快速切换到正常的节点,保障缓存服务不中断。

  6. 限流和熔断机制:
    在系统中实施限流和熔断机制,当流量或错误超过一定阈值时,暂时阻止部分请求,保护数据库和系统不被过载。

  7. 异步队列:
    当缓存失效后,可以将数据库的读取操作放入异步队列中,用异步处理的方式来缓解瞬时流量对数据库的冲击。

三 缓存击穿

缓存击穿指的是缓存中没有但数据库中有的数据(一般是热点数据)在缓存失效的瞬间,同时有大量并发请求这个数据点,这些请求会直接穿透缓存,全部落到数据库上,造成数据库短时间内的高压力。这与缓存穿透不同,缓存穿透是查询不存在的数据,而缓存击穿则是查询存在但是缓存刚好失效的数据。

解决方案:
  1. 使用互斥锁:
    对于同一个数据点,在缓存失效时,通过加锁或同步机制,保证不管有多少并发请求,只允许一个请求去数据库查询数据,并更新缓存,其他请求等待缓存被更新后直接从缓存中获取数据。常见的做法是使用分布式锁。

  2. 设置热点数据永不过期:
    对于一些访问频率非常高的热点数据,可以设置缓存永不过期,或者缓存失效后由后台维护线程负责更新,而不是由用户请求触发更新。

  3. 使用双缓存机制(Cache Aside pattern):
    当缓存失效时,并不立即删除缓存,而是使用另一个缓存进行更新操作。在新缓存更新完成之前,所有的读请求仍然访问的是旧的缓存。更新完成后再进行切换。

  4. 提前更新缓存:
    对于即将到期的数据,可以通过定时任务来检测并更新它。当检测到缓存数据即将到期时,可以提前异步地更新缓存。

  5. 给缓存设置合理的过期时间:
    对于一些热点数据,根据业务场景设置合理的过期时间,避免大量并发请求在同一时刻击穿缓存。

  6. 分布式缓存+本地缓存:
    可以在本地实现一层缓存,以减少对分布式缓存服务的访问频率,即使分布式缓存服务的数据过期,本地缓存仍然可以提供服务。

  7. 读写分离和负载均衡:
    数据库使用读写分离架构和负载均衡策略,将读操作分散到多个从库,减少对主库的直接压力。

四 数据不一致

缓存和数据库数据不一致的问题通常是由于缓存层与数据库层之间的数据同步策略不当导致的。这可能发生在以下几种情况:

1. 写操作没有同时更新缓存与数据库。
2. 缓存过期或被删除,而数据库中的数据在此期间被修改。
3. 分布式系统中由于网络延迟或其他问题导致的数据同步延迟。
4. 数据库事务回滚,但缓存更新已经发生。

这些问题可能导致用户获取到过时的数据,影响用户体验,并可能引发更严重的数据一致性问题。

解决方法
  1. 缓存更新策略:

    缓存延迟双删:更新数据库数据后,先删除缓存,然后延迟一小段时间再次删除缓存,以确保请求在这段时间内若读取了旧数据,也会再次删除缓存,从而读到最新数据。

    Write/Read Through Cache:利用缓存提供的写通(Writethrough)或读取通(Read through)策略,让缓存管理器负责数据的读写,确保数据的一致性。

    Write Behind Caching:更新操作首先在缓存中执行,然后异步批量更新到数据库,这种策略要考虑数据丢失的风险和数据一致性的问题。

  2. 数据库触发器:
    使用数据库触发器在数据发生变化时自动更新缓存,确保数据一致性。

  3. 事务消息:
    通过使用支持事务的消息队列,将缓存操作和数据库操作放到同一个事务中,确保两者要么都成功,要么都失败。

  4. 最终一致性:
    接受在某个时间窗口内缓存与数据库中的数据不一致,但是通过后台异步进程定期校对并同步数据,保证最终一致性。

  5. 使用分布式缓存解决方案:
    选择支持一致性哈希、数据同步等特性的分布式缓存解决方案,如Redis Cluster,保证数据在多个节点之间的一致性。

  6. 版本号/时间戳校验:
    给数据库记录添加版本号或时间戳,缓存数据时一同缓存这个版本信息,每次读取缓存数据时都检查版本或时间戳是否相符,若不符则重新从数据库加载。

  7. 强制缓存过期:
    设置较短的缓存过期时间,确保数据定期从数据库中刷新。

###五 数据并发竞争
数据并发竞争访问问题,通常指的是多个客户端或线程同时对同一数据进行读写操作时,由于没有妥善的并发控制措施导致数据出现不一致或者丢失的情况。这个问题在分布式系统和多用户系统中尤为常见,尤其是在使用像Redis这样的缓存系统时也会遇到。

出现问题的场景:
计数器更新:比如用Redis计数器统计网站点击量,如果多个请求同时更新计数器,可能会因为读写操作不是原子性导致计数器丢失更新。
库存扣减:在电商场景中,多个用户同时下单扣减库存,可能会导致超卖。
分布式锁:多个进程需要对同一资源进行操作时,需要使用锁来保证同时只有一个操作可以执行。
Session共享:在分布式部署的Web应用中,多个服务器上的并发请求需要共享Session信息,可能导致Session数据不一致。

解决方案:

  1. 使用事务:Redis事务可以通过MULTI和EXEC命令来确保一系列命令的原子性执行。

  2. 使用Lua脚本:Redis可以执行Lua脚本,Lua脚本在执行过程中会被当作一个整体执行,这保证了操作的原子性。

  3. 使用分布式锁:可以实现一个基于Redis的分布式锁来控制资源的并发访问。比如使用SETNX命令实现锁的获取和释放。

  4. 乐观锁/Optimistic Locking:使用WATCH命令监视一个或多个键,如果在执行事务前这些键没有被其他命令改变,事务才会被执行。

  5. 悲观锁/Pessimistic Locking:对于关键业务,可以选择先对数据加锁,在业务处理完成后再解锁,避免其他客户端的访问。

  6. 限流措施:通过限流算法如令牌桶、漏桶等,控制对某一资源的并发访问数,减少并发冲突。

  7. 消息队列:使用消息队列将并发请求串行化处理,确保对共享资源的访问是有序的。

在这里插入图片描述

来源:https://blоg.сsdn.nеt/yаng073402/аrtiсlе/dеtаils/134903304

智能推荐

每日三题(5.5) 1.一家公司正在建立一个系统来提

标签:PMP题库  scrum  学习  

1、前言 随着互联网从简单的单向浏览请求&#x

标签:缓存  

1、前言 随着互联网从简单的单向浏览请求&#x

标签:缓存  

 1.反转单链表

标签:题目  leetcode  链表  算法  数据结构  c语言  

系统设计-经典场景电商业务之下单

标签:下单  场景  经典  商业  系统  

翻译自:https://medium.com/geekculture/top-10-system-design-interview-questions-10f7b5ea123d在我作为微软和Facebook的高级软件工程师和面试官的10年时间里,我曾与数百名应聘者一起工作,帮助他们解决不同的系统设计问题。开发人员往往会在

标签:十大经典  架构  面试题  系统  

题目链接:蓝桥杯算法提高VIP-夺宝奇兵 - C语言网 (dotcp

标签:c++  蓝桥杯  动态规划  算法  

P1807 最长路 /

标签:拓扑学  算法  图论  

如有问题请及时指正select version();数据准备-- 1.学生表-- S# 学生编号,Sname 学生姓名,Sage 出生年月,Sse

标签:练习题  经典  sql  _MySQL  

7-4每日三题 1.敏捷项目团队需要一个新的项目组件的集成工具。项目团队应如何计划和监督

标签:PMP题库  大数据  scrum  学习  

6-13每日三题 1.下面哪一个不是敏捷项目经理的特征?  A

标签:PMP题库  日常学习  scrum  学习  

背景双十一大促期间, 收到客服反馈通知,说 APP 领券接口缓慢。找到一个case,通过调用链路发现,是操作redis 缓慢,并且还搜到一些redis 异常。最后定位到原因:是发券场景下拿redis 做了一个缓存券批次的操作,记录用户当天领取的所有券批次发券场景: key = userId, value = 券批次ID 列表, 而redis 查询发现多了许多大key,体现在 一个用户领取的几千甚至上万张优惠券,导致Redis 查询缓慢,甚至异常。至于为何有的用户会领取这么多优惠券呢。联系风控发现,这些个用户是来薅羊毛的,但是风控没有拦截到,导致服务这边出现异常。虽说最终原因不是我的问题,但是Redis 大 key 问题还是比较有意思的

标签:redis  keyRedis  key  

猜你喜欢

1.282. 石子合并 - AcWing题库 题目简单说明:将·1

标签:算法  

目录 1.1冒泡排序

标签:排序算法  算法  数据结构  

一、准备工作 1、学生表 Student(SId,Sname,S

标签:sql  数据库  mysql  

一、简介    今天是《Net 高级调试》的第十五篇文章,这个系列的文章也快结束了,但是我们深入学习的脚步还不能停止。上一篇文件我们介绍了C# 中一些锁的实现逻辑,并做到了眼见为实的演示给大家它们底层是如何实现的,今天这篇文件就主要介绍一些如何查找和解决在项目调试中遇到的锁的问题,比如:死锁、孤立锁、线程中止和终结期挂起,我们会看到表象是什么,也会做到遇到这样问题,我们如何解决问题,我们每一个操作都能做到有的放矢。我们学了锁的实现,现在又要学习有关锁的解决办法,就是让我们做到知其一,也要知其二,这些是 Net 框架的底层,了解更深,对于我们调试更有利。当然了,第一次看视频或者看

标签:故障  高级  经典  NET  

💡 近日,在极狐 TechTalk 直播

标签:code review  代码评审  代码规范  代码质量  devops  

来源:https://segmentfault.com/a/11900000382926441. 用预处理指令#define 声明一个常数

标签:语言  收藏  经典  

zhe大家好今天来写第一关的白银挑战-链表经典问题. 两个链表的第一个公共结点

标签:算法村  链表  笔记  数据结构  

相关问题

相关文章

热门文章

推荐文章

相关标签