文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

Redis缓存总结:淘汰机制、缓存雪崩、数据不一致....

2024-12-03 12:32

关注

在实际的工作项目中, 缓存成为高并发、高性能架构的关键组件 ,那么Redis为什么可以作为缓存使用呢?首先可以作为缓存的两个主要特征:

由于Redis 天然就具有这两个特征,Redis基于内存操作的,且其具有完善的数据淘汰机制,十分适合作为缓存组件。

其中,基于内存操作,容量可以为32-96GB,且操作时间平均为100ns,操作效率高。而且数据淘汰机制众多,在Redis 4.0 后就有8种了促使Redis作为缓存可以适用很多场景。

那Redis缓存为什么需要数据淘汰机制呢?有哪8种数据淘汰机制呢?

数据淘汰机制

Redis缓存基于内存实现的,则其缓存其容量是有限的,当出现缓存被写满的情况,那么这时Redis该如何处理呢?

Redis对于缓存被写满的情况,Redis就需要缓存数据淘汰机制,通过一定淘汰规则将一些数据刷选出来删除,让缓存服务可再使用。那么Redis使用哪些淘汰策略进行刷选删除数据?

在Redis 4.0 之后,Redis 缓存淘汰策略6+2种,包括分成三大类:

Note: LRU( 最近最少使用,Least Recently Used)算法, LRU维护一个双向链表 ,链表的头和尾分别表示 MRU 端和 LRU 端,分别代表最近最常使用的数据和最近最不常用的数据。

LRU 算法在实际实现时,需要用链表管理所有的缓存数据,这会带来额外的空间开销。而且,当有数据被访问时,需要在链表上把该数据移动到 MRU 端,如果有大量数据被访问,就会带来很多链表移动操作,会很耗时,进而会降低 Redis 缓存性能。

其中,LRU和LFU 基于Redis的对象结构 redisObject 的 lru 和 refcount 属性实现的:

  1. typedef struct redisObject { 
  2. unsigned type:4
  3. unsigned encoding:4
  4. // 对象最后一次被访问的时间 
  5. unsigned lru:LRU_BITS;  
  6. int refcount; 
  7. void *ptr; 
  8. } robj; 

Redis 的 LRU 会使用 redisObject 的 lru 记录最近一次被访问的时间,随机选取参数 maxmemory-samples 配置的数量作为候选集合,在其中选择 lru 属性值最小的数据淘汰出去。

在实际项目中,那么该如何选择数据淘汰机制呢?

在理解了Redis缓存淘汰机制后,来看看Redis作为缓存其有多少种模式呢?

Redis缓存模式

Redis缓存模式基于是否接收写请求,可以分成只读缓存和读写缓存:

只读缓存:只处理读操作,所有的更新操作都在数据库中,这样数据不会有丢失的风险。

读写缓存,读写操作都在缓存中执行,出现宕机故障,会导致数据丢失。缓存写回数据到数据库有分成两种同步和异步:

  • 同步:访问性能偏低,其更加侧重于保证数据可靠性

  • Read-Throug模式

  • Write-Through模式

  • 异步:有数据丢失风险,其侧重于提供低延迟访问

  • Write-Behind模式

Cache Aside模式

查询数据先从缓存读取数据,如果缓存中不存在,则再到数据库中读取数据,获取到数据之后更新到缓存Cache中, 但更新数据操作,会先去更新数据库种的数据,然后将缓存种的数据失效。

而且Cache Aside模式会存在并发风险:执行读操作未命中缓存,然后查询数据库中取数据,数据已经查询到还没放入缓存,同时一个更新写操作让缓存失效,然后读操作再把查询到数据加载缓存,导致缓存的脏数据。

Read/Write-Throug模式

查询数据和更新数据都直接访问缓存服务, 缓存服务同步方式地将数据更新到数据库 。出现脏数据的概率较低,但是就强依赖缓存,对缓存服务的稳定性有较大要求,但同步更新会导致其性能不好。

Write Behind模式

查询数据和更新数据都直接访问缓存服务, 但缓存服务使用异步方式地将数据更新到数据库(通过异步任务) 速度快,效率会非常高,但是数据的一致性比较差,还可能会有数据的丢失情况,实现逻辑也较为复杂。

在实际项目开发中根据实际的业务场景需求来进行选择缓存模式。那了解上述后,我们的应用中为什么需要使用到 redis 缓存呢?

在应用使用 Redis 缓存可以提高系统性能和并发,主要体现在

虽然使用Redis缓存可以大大提升系统的性能,但是使用了缓存,会出现一些问题,比如,缓存与数据库双向不一致、缓存雪崩等,对于出现的这些问题该怎么解决呢?

使用缓存常见的问题

使用了缓存,会出现一些问题,主要体现在:

缓存与数据库数据不一致

只读缓存( Cache Aside 模式)

对于 只读缓存( Cache Aside 模式) ,读 操作都发生在缓存中 ,数据不一致只会发生在 删改操作 上(新增操作不会,因为新增只会在数据库处理),当发生删改操作时,缓存将数据中标志为无效和更新数据库。因此在更新数据库和删除缓存值的过程中,无论这两个操作的执行顺序谁先谁后,只要有一个操作失败了就会出现数据不一致的情况。

总结出, 当不存在并发的情况使用重试机制(消息队列使用),当存在高并发的情况,使用延迟双删除(在第一次删除后,睡眠一定时间后,再进行删除) ,具体如下:

操作顺序 是否高并发 潜在问题 现象 应对方案
先删除缓存,再更新数据库 缓存删除成功,数据库更新失败 读到数据库的旧值 重试机制(数据库更新)
先更新数据库,再删除缓存 数据库更新成功,缓存删除失败 读到缓存的旧值 重试机制(缓存删除)
先删除缓存,再更新数据库 缓存删除后,尚未更新数据库,有并发读请求 并发读请求读到数据库旧值,并更新到缓存,导致之后的读请求读到旧值 延迟双删()
先更新数据库,再删除缓存 数据库更新成功,尚未删除缓存 读到缓存的旧值 不一致的情况短暂存在,对业务影响较小

NOTE:

延迟双删除伪代码:

  1. redis.delKey(X) 
  2. db.update(X) 
  3. Thread.sleep(N) 
  4. redis.delKey(X) 

读写缓存(Read/Write-Throug、Write Behind模式 )

对于读写缓存,写操作都发生在缓存中,后再更新数据库,只要有一个操作失败了就会出现数据不一致的情况。

总结出,当不存在并发的情况使用重试机制(消息队列使用),当存在高并发的情况,使用分布锁。具体如下:

操作顺序 是否高    并发 潜在问题 现象 应对方案
先更新缓存,再更新数据库 缓存更新成功,数据库更新失败 会从缓存中读到最新值,短期影响不大 重试机制(数据库更新)
先更新数据库,再更新缓存 数据库更新成功,缓存更新失败 会从缓存读到旧值 重试机制(缓存删除)
先更新数据库,再更新缓存 写+读并发 线程A先更新数据库,之后线程B读取数据,之后线程A更新缓存 B会命中缓存,读取到旧值 A更新缓存前,对业务有短暂影响
先更新缓存,再更新数据库 写+读并发 线程A先更新缓存成功,之后线程B读取数据,此时线程B命中缓存,读取到最新值后返回,之后线程A更新数据库成功 B会命中缓存,读取到最新值 业务没影响
先更新数据库,再更新缓存 写+写并发 线程A和线程B同时更新同一条数据,更新数据库的顺序是先A后B,但更新缓存时顺序是先B后A,这会导致数据库和缓存的不一致 数据库和缓存的不一致 写操作加分布式锁
先更新缓存,再更新数据库 写+写并发 线程A和线程B同时更新同一条数据,更新缓存的顺序是先A后B,但是更新数据库的顺序是先B后A,这也会导致数据库和缓存的不一致 数据库和缓存的不一致 写操作加分布式锁

缓存雪崩

缓存雪崩,由于缓存中有大量数据同时过期失效或者缓存出现宕机,大量的应用请求无法在 Redis 缓存中进行处理,进而发送到数据库层导致数据库层的压力激增,严重的会造成数据库宕机。

对于缓存中有大量数据同时过期,导致大量请求无法得到处理, 解决方式:

对于缓存出现宕机,解决方式:

缓存穿透

缓存穿透,数据在数据库和缓存中都不存在,这样就导致查询数据,在缓存中找不到对应 key 的 value ,都要去数据库再查询一遍,然后返回空(相当于进行了两次无用的查询)。

当有大量访问请求,且其绕过缓存直接查数据库,导致数据库层的压力激增,严重的会造成数据库宕机。

对于缓存穿透,解决方式:

缓存击穿

缓存击穿,针对某个访问非常频繁的热点数据过期失效,导致访问无法在缓存中进行处理,进而会有导致大量的直接请求数据库,从而使得数据库层的压力激增,严重的会造成数据库宕机。

对于缓存击穿,解决方式:

总结

在大多数业务场景下,Redis缓存作为只读缓存使用。针对只读缓存来说, 优先使用先更新数据库再删除缓存的方法保证数据一致性 。

其中,缓存雪崩,缓存穿透,缓存击穿三大问题的原因和解决方式

问题 原因 解决方式
缓存雪崩

大量数据同时过期失

效缓存出现宕机

数据预热

设置不同的过期时间

双层缓存策略

服务降级

服务熔断

限流机制

缓存穿透 数据在数据库和缓存中都不存在

缓存空值或缺省

值布隆过滤器( BloomFilter )

缓存击穿 访问非常频繁的热点数据过期失效 对于访问特别频繁的热点数据,不设置过期时间

 

来源:Ccww技术博客内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯