Redis 核心技术与实战
蒋德钧
中科院计算所副研究员
81696 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 53 讲
开篇词 (1讲)
实践篇 (28讲)
Redis 核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

24 | 替换策略:缓存满了怎么办?

Redis缓存对应的模式
设置缓存容量大小
缓存策略选择
写回数据库
干净数据和脏数据
有置顶的需求
业务应用中的数据访问频率相差不大
优先使用allkeys-lru策略
Redis中的简化实现
筛选数据
Least Recently Used
allkeys-lfu
allkeys-random
allkeys-lru
volatile-lfu
volatile-lru
volatile-random
volatile-ttl
淘汰候选数据集的范围
会进行淘汰的策略
不进行数据淘汰的策略
缓存数据的淘汰机制
重要机制
依据和方法
数据访问局部性
影响性价比
提升应用响应速度
使用内存保存数据
每课一问
总结
处理被淘汰的数据
使用建议
LRU算法
数据淘汰策略
缓存淘汰策略
缓存淘汰机制
缓存容量设置
Redis缓存
缓存替换策略

该思维导图由 AI 生成,仅供参考

你好,我是蒋德钧。
Redis 缓存使用内存来保存数据,避免业务应用从后端数据库中读取数据,可以提升应用的响应速度。那么,如果我们把所有要访问的数据都放入缓存,是不是一个很好的设计选择呢?其实,这样做的性价比反而不高。
举个例子吧。MySQL 中有 1TB 的数据,如果我们使用 Redis 把这 1TB 的数据都缓存起来,虽然应用都能在内存中访问数据了,但是,这样配置并不合理,因为性价比很低。一方面,1TB 内存的价格大约是 3.5 万元,而 1TB 磁盘的价格大约是 1000 元。另一方面,数据访问都是有局部性的,也就是我们通常所说的“八二原理”,80% 的请求实际只访问了 20% 的数据。所以,用 1TB 的内存做缓存,并没有必要。
为了保证较高的性价比,缓存的空间容量必然要小于后端数据库的数据总量。不过,内存大小毕竟有限,随着要缓存的数据量越来越大,有限的缓存空间不可避免地会被写满。此时,该怎么办呢?
解决这个问题就涉及到缓存系统的一个重要机制,即缓存数据的淘汰机制。简单来说,数据淘汰机制包括两步:第一,根据一定的策略,筛选出对应用访问来说“不重要”的数据;第二,将这些数据从缓存中删除,为新来的数据腾出空间,
这节课上,我就来和你聊聊缓存满了之后的数据淘汰机制。通常,我们也把它叫作缓存替换机制,同时还会讲到一系列选择淘汰数据的具体策略。了解了数据淘汰机制和相应策略,我们才可以选择合理的 Redis 配置,提高缓存命中率,提升应用的访问性能。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

Redis缓存淘汰策略是保证缓存性价比的关键。文章介绍了8种淘汰策略,分为不进行淘汰的策略和会进行淘汰的策略。对于进行淘汰的策略,根据淘汰候选数据集的范围又分为在设置了过期时间的数据中进行淘汰和在所有数据范围内进行淘汰。作者详细解释了volatile-ttl、volatile-random、volatile-lru、volatile-lfu和allkeys-lru、allkeys-random、allkeys-lfu策略的具体筛选规则和工作机制。特别是对LRU算法进行了深入解析,指出Redis中对LRU算法进行了简化以减轻对缓存性能的影响。最后,作者给出了三条使用建议,建议优先使用allkeys-lru策略,或根据业务特点选择合适的淘汰策略。整体而言,本文提供了深入的技术分析和建议,对于理解缓存替换策略和合理设置缓存容量具有重要参考价值。 文章还介绍了被淘汰数据的处理方法,强调了干净数据和脏数据的区别,以及在Redis中被淘汰的数据无论干净与否都会被删除的特点。此外,对于缓存替换策略的选择,建议优先考虑是否有始终会被频繁访问的数据,并结合实际应用的数据总量、热数据的体量以及成本预算来设置缓存空间大小。 总的来说,本文深入探讨了Redis缓存淘汰策略和被淘汰数据的处理方法,为读者提供了重要的技术分析和实用建议。文章内容涵盖了缓存替换策略的具体筛选规则、工作机制以及对应的使用建议,对于需要理解缓存性能优化和合理设置缓存容量的读者具有重要参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Redis 核心技术与实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(42)

  • 最新
  • 精选
  • Mr.蜜
    我发现一个问题,在淘汰策略上,我的记忆中,他一直是默认volatile-lru,而且在百度上搜索,大多数也都是默认volatile-lru。而我在前几周也看到与你有相同的说法,默认是noeviction,所以我查看了多个版本的配置文件,从中了解到,在redis3.0之前,默认是volatile-lru;在redis3.0之后(包括3.0),默认淘汰策略则是noeviction。所以这个地方需要强调一下。

    作者回复: 谢谢指出版本上的差别,赞仔细认真!

    2020-11-06
    154
  • humor
    能进入候选集合的数据的 lru 字段值必须小于候选集合中最小的 lru 值。 感觉这句话有问题,如果能进入候选集合的数据的lru字段值都小于候选集合中的最小的lru值的话,每次淘汰的肯定是刚进入候选集合的这条数据啊,这样这条被选择进行候选集合的数据就没有必要再进入候选集合了啊,直接删除就可以了吧

    作者回复: 在实际运行时,每次往候选集中插入的数据可能不止一个,而在淘汰数据时,也是会根据使用内存量超过maxmemory的情况,来决定要淘汰的数据量,所以可能也不止一个数据被淘汰。候选集的作用是先把符合条件(lru值小)的数据准备好。候选集本身是会按照lru值大小排序的,等待要淘汰时,会根据要淘汰的量,从候选集中淘汰数据。所以,并不是刚进入候选集就立马就淘汰了。准备候选集和淘汰数据实际是两个解耦的逻辑操作。

    2020-10-12
    7
    48
  • 不正经、绅士
    能进入候选集合的数据的 lru 字段值必须小于候选集合中最小的 lru 值。 这里有个疑问,请教老师,这样第二次及后续进入的备选淘汰集合中的数据lru都小于第一次的,淘汰的也是lru最小的,那第一次进入淘汰集合的数据这样不就不会被选中淘汰了呢

    作者回复: 是有这种可能的,第一次进入候选集合的数据是随机选取的,数据的lru值可能大可能小。第二次及后续再进入候选集的数据的lru值需要小于候选集中的最小lru值。 同时,候选集的实现是一个链表,数据是按照lru值排序的,链表头是lru值最大的,链表尾是lru值最小的。当第二次及后续进入候选集的数据lru更小,但是候选集中已经没有空位置时,候选集链表头的数据会被移出候选集,把位置空出来,给新进入的数据。这样的话,这个被移出的数据就不会作为被淘汰的候选数据了。

    2020-10-12
    5
    22
  • 有生之年
    老师,您好,如果redis既做缓存,又作存储使用,是不是就不能设置allkeys相关的配置了

    作者回复: 因为allkeys是在所有的键值对中进行筛选淘汰,所以,如果redis做存储,相应的数据应该是不希望被淘汰的(除非应用自己删除),此时用allkeys就不合适了。 一般不建议一个Redis实例同时做缓存和做存储,可以分开用不同实例。

    2020-12-07
    20
  • 好好学习
    老师好, 这里是不是有些矛盾呢? 文中说"如果业务中有置顶的需求,比如置顶新闻、置顶视频,可以使用 volatile-lru 策略,同时不给这些置顶数据设置过期时间。" volatile-lru 不是只针对设置了过期时间的key才会生效吗? 这里又说不给这些数据设置过期时间..

    作者回复: 使用volatile-lru策略的同时给置顶数据不设置过期时间,就是为了把置顶数据和非置顶数据区分开来。对置顶数据不设置过期时间,就不会被volatile-lru淘汰,可以一直置顶。而其他非置顶数据可以正常被volatile-lru淘汰掉。 如果用allkeys的策略,就无法区分置顶和非置顶数据了,都是用统一的策略了。

    2020-11-27
    15
  • 沈寅
    volatile-开头的策略 ,如果一个key还未过期,有可能被删除吗?

    作者回复: 有可能会被删除的。 volatile-*策略是从设置了过期时间的key中进行淘汰,如果内存不够了,即使key的过期时间还未到,也可能按照策略被选出来淘汰掉。

    2020-11-02
    9
    13
  • Kaito
    Redis在用作缓存时,使用只读缓存或读写缓存的哪种模式? 1、只读缓存模式:每次修改直接写入后端数据库,如果Redis缓存不命中,则什么都不用操作,如果Redis缓存命中,则删除缓存中的数据,待下次读取时从后端数据库中加载最新值到缓存中。 2、读写缓存模式+同步直写策略:由于Redis在淘汰数据时,直接在内部删除键值对,外部无法介入处理脏数据写回数据库,所以使用Redis作读写缓存时,只能采用同步直写策略,修改缓存的同时也要写入到后端数据库中,从而保证修改操作不被丢失。但这种方案在并发场景下会导致数据库和缓存的不一致,需要在特定业务场景下或者配合分布式锁使用。 当一个系统引入缓存时,需要面临最大的问题就是,如何保证缓存和后端数据库的一致性问题,最常见的3个解决方案分别是Cache Aside、Read/Write Throught和Write Back缓存更新策略。 1、Cache Aside策略:就是文章所讲的只读缓存模式。读操作命中缓存直接返回,否则从后端数据库加载到缓存再返回。写操作直接更新数据库,然后删除缓存。这种策略的优点是一切以后端数据库为准,可以保证缓存和数据库的一致性。缺点是写操作会让缓存失效,再次读取时需要从数据库中加载。这种策略是我们在开发软件时最常用的,在使用Memcached或Redis时一般都采用这种方案。 2、Read/Write Throught策略:应用层读写只需要操作缓存,不需要关心后端数据库。应用层在操作缓存时,缓存层会自动从数据库中加载或写回到数据库中,这种策略的优点是,对于应用层的使用非常友好,只需要操作缓存即可,缺点是需要缓存层支持和后端数据库的联动。 3、Write Back策略:类似于文章所讲的读写缓存模式+异步写回策略。写操作只写缓存,比较简单。而读操作如果命中缓存则直接返回,否则需要从数据库中加载到缓存中,在加载之前,如果缓存已满,则先把需要淘汰的缓存数据写回到后端数据库中,再把对应的数据放入到缓存中。这种策略的优点是,写操作飞快(只写缓存),缺点是如果数据还未来得及写入后端数据库,系统发生异常会导致缓存和数据库的不一致。这种策略经常使用在操作系统Page Cache中,或者应对大量写操作的数据库引擎中。 除了以上提到的缓存和数据库的更新策略之外,还有一个问题就是操作缓存或数据库发生异常时如何处理?例如缓存操作成功,数据库操作失败,或者反过来,还是有可能会产生不一致的情况。 比较简单的解决方案是,根据业务设计好更新缓存和数据库的先后顺序来降低影响,或者给缓存设置较短的有效期来降低不一致的时间。如果需要严格保证缓存和数据库的一致性,即保证两者操作的原子性,这就涉及到分布式事务问题了,常见的解决方案就是我们经常听到的两阶段提交(2PC)、三阶段提交(3PC)、TCC、消息队列等方式来保证了,方案也会比较复杂,一般用在对于一致性要求较高的业务场景中。
    2020-10-12
    37
    278
  • yeek
    记录几个问题: 1. 淘汰对当前请求的延迟问题; 2. 淘汰数据的上限是多少?仅满足当前set所需的内存空间么? 3. 如果随机多次依然不存在比候选队列中最小lru还小的数据,且内存空间还需要继续释放,是否有执行时间上限?
    2020-10-12
    6
  • 学而不思则罔
    缓存淘汰这里有个疑问,做分布式锁的lock_key一般都会带上expire,这个时候lock_key如果被淘汰了不是会导致锁失效吗?
    2021-04-20
    3
    3
  • Watson
    原文:如果候选数据集中的数据个数达到了 maxmemory-samples,Redis 就把候选数据集中 lru 字段值最小的数据淘汰出去。 请教老师,是否存在maxmemory-samples 没达到个数,但是redis内存满了的情况,如果存在这种情况,redis淘汰机制没有启动的时候,redis内存满了,会发生什么神奇之旅呢?
    2020-10-14
    4
    3
收起评论
显示
设置
留言
42
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部