24 | 替换策略：缓存满了怎么办？
该思维导图由 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-06154
humor能进入候选集合的数据的 lru 字段值必须小于候选集合中最小的 lru 值。 感觉这句话有问题，如果能进入候选集合的数据的lru字段值都小于候选集合中的最小的lru值的话，每次淘汰的肯定是刚进入候选集合的这条数据啊，这样这条被选择进行候选集合的数据就没有必要再进入候选集合了啊，直接删除就可以了吧作者回复: 在实际运行时，每次往候选集中插入的数据可能不止一个，而在淘汰数据时，也是会根据使用内存量超过maxmemory的情况，来决定要淘汰的数据量，所以可能也不止一个数据被淘汰。候选集的作用是先把符合条件（lru值小）的数据准备好。候选集本身是会按照lru值大小排序的，等待要淘汰时，会根据要淘汰的量，从候选集中淘汰数据。所以，并不是刚进入候选集就立马就淘汰了。准备候选集和淘汰数据实际是两个解耦的逻辑操作。
2020-10-12748
不正经、绅士能进入候选集合的数据的 lru 字段值必须小于候选集合中最小的 lru 值。 这里有个疑问，请教老师，这样第二次及后续进入的备选淘汰集合中的数据lru都小于第一次的，淘汰的也是lru最小的，那第一次进入淘汰集合的数据这样不就不会被选中淘汰了呢作者回复: 是有这种可能的，第一次进入候选集合的数据是随机选取的，数据的lru值可能大可能小。第二次及后续再进入候选集的数据的lru值需要小于候选集中的最小lru值。 同时，候选集的实现是一个链表，数据是按照lru值排序的，链表头是lru值最大的，链表尾是lru值最小的。当第二次及后续进入候选集的数据lru更小，但是候选集中已经没有空位置时，候选集链表头的数据会被移出候选集，把位置空出来，给新进入的数据。这样的话，这个被移出的数据就不会作为被淘汰的候选数据了。
2020-10-12522
有生之年老师，您好，如果redis既做缓存，又作存储使用，是不是就不能设置allkeys相关的配置了作者回复: 因为allkeys是在所有的键值对中进行筛选淘汰，所以，如果redis做存储，相应的数据应该是不希望被淘汰的（除非应用自己删除），此时用allkeys就不合适了。 一般不建议一个Redis实例同时做缓存和做存储，可以分开用不同实例。
2020-12-0720
好好学习老师好, 这里是不是有些矛盾呢? 文中说"如果业务中有置顶的需求，比如置顶新闻、置顶视频，可以使用 volatile-lru 策略，同时不给这些置顶数据设置过期时间。" volatile-lru 不是只针对设置了过期时间的key才会生效吗? 这里又说不给这些数据设置过期时间..作者回复: 使用volatile-lru策略的同时给置顶数据不设置过期时间，就是为了把置顶数据和非置顶数据区分开来。对置顶数据不设置过期时间，就不会被volatile-lru淘汰，可以一直置顶。而其他非置顶数据可以正常被volatile-lru淘汰掉。 如果用allkeys的策略，就无法区分置顶和非置顶数据了，都是用统一的策略了。
2020-11-2715
沈寅volatile-开头的策略 ，如果一个key还未过期，有可能被删除吗？作者回复: 有可能会被删除的。 volatile-*策略是从设置了过期时间的key中进行淘汰，如果内存不够了，即使key的过期时间还未到，也可能按照策略被选出来淘汰掉。
2020-11-02913
KaitoRedis在用作缓存时，使用只读缓存或读写缓存的哪种模式？ 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-1237278
yeek记录几个问题： 1. 淘汰对当前请求的延迟问题； 2. 淘汰数据的上限是多少？仅满足当前set所需的内存空间么？ 3. 如果随机多次依然不存在比候选队列中最小lru还小的数据，且内存空间还需要继续释放，是否有执行时间上限？2020-10-126
学而不思则罔缓存淘汰这里有个疑问，做分布式锁的lock_key一般都会带上expire，这个时候lock_key如果被淘汰了不是会导致锁失效吗？2021-04-2033
Watson原文：如果候选数据集中的数据个数达到了 maxmemory-samples，Redis 就把候选数据集中 lru 字段值最小的数据淘汰出去。 请教老师，是否存在maxmemory-samples 没达到个数，但是redis内存满了的情况，如果存在这种情况，redis淘汰机制没有启动的时候，redis内存满了，会发生什么神奇之旅呢？2020-10-1443
