Redis缓存用不好，淘汰策略到底怎么搞才有效呢？

综合自多位资深开发者的实践经验分享及技术社区讨论）

Redis缓存用不好,淘汰策略到底怎么搞才有效呢？这个问题确实让很多开发者头疼，选错了策略，缓存要么很快被塞满，频繁淘汰热点数据，导致数据库压力山大；要么就像个无底洞，存了一堆再也不会被访问的“垃圾”数据，白白浪费宝贵的内存，搞定淘汰策略没那么复杂，关键在于理解你的业务数据是什么样的，对症下药”。

我们得明白Redis提供了哪些主要的“武器”，别被那些专业名词吓到，我们可以用更生活化的方式来理解它们。

noeviction： 这是最“霸道”的一种，当内存不够时，它直接摆挑子，对新来的写入请求说“不”，并返回错误，这就像你家衣柜满了，你老婆还想买新衣服，你坚决不同意，告诉她“没地儿放了，别买了！”这种策略能保证现有的数据绝对不会丢失，但代价是可能造成写服务不可用，它只适用于你非常确定缓存的数据绝对不能丢，并且你愿意承受在内存满时写入失败的风险的场景，你把缓存当成一个非常快速且重要的持久化存储来用。

allkeys-lru： 这是最常用、最“经典”的策略，LRU的意思是“最近最少使用”，它会尝试淘汰掉那些“最近一段时间内”被访问得最少的键，这非常符合“二八定律”，即80%的访问都集中在20%的热点数据上，它就像你家整理衣柜，你会把最近一年都没穿过的旧衣服捐掉，给新买的衣服腾地方，这个策略非常适合你无法明确区分数据重要性的场景，比如用户会话、热点新闻列表、大部分的商品信息缓存等，它能有效地把热点数据保留在内存里。

volatile-lru： 这个是allkeys-lru的“温和版”，它只对那些设置了过期时间的键进行LRU淘汰，对于那些没设置过期时间的键，即使内存再紧张，它也绝不碰一下，这就像你家里有个放重要文件的书架和一个放杂志的报刊架，当空间不足时，你只会去清理过期的旧杂志，而书架上重要的文件无论放多久都不会扔，这个策略适合你的数据能明显分为两类：一类是“临时数据”（如短信验证码、临时会话），需要定期清理；另一类是“重要基础数据”（如城市列表、部门信息），需要永久驻留缓存。

allkeys-random： 顾名思义，就是随机淘汰，不管数据是热是冷，是老是新，随便挑一个踢出去，这听起来很随意，但在某些特定场景下反而有奇效，如果你的所有数据访问频率都差不多，都是“平权”的，没有明显的热点，那么用LRU算法反而需要额外开销来记录访问顺序，这时候用随机淘汰既简单又高效，就像你有一堆完全一样的袜子，随便拿两只穿就行，没必要纠结哪两只最近穿得少。

volatile-random： 和volatile-lru类似，它只在设置了过期时间的键中随机淘汰。

volatile-ttl： 这个策略比较“智能”，它会优先淘汰那些“剩余寿命最短”的键，TTL就是“存活时间”，它认为，一个快过期的键，反正也马上就要被自动删除了，不如提前把它清掉来腾空间，这就像冰箱里的酸奶，你看哪瓶最先到期，就优先喝掉哪瓶，这个策略特别适合缓存大量有固定生命周期的数据，比如限时优惠券、当天有效的排行榜等。

到底怎么选才有效呢？关键在于回答以下几个问题：

第一步：你的数据有没有“永久居民”？ 如果你的缓存里有一些非常重要的配置数据、基础数据，你希望它们一旦加载就永远不被自动淘汰（除非手动删除），那么你就不能选择allkeys开头的策略（allkeys-lru, allkeys-random），因为它们会无差别攻击，你应该选择volatile开头的策略（volatile-lru或volatile-ttl），并且记得只给那些临时数据设置过期时间，不给“永久居民”数据设置过期时间。

第二步：你的数据访问有“热点”吗？ 如果你的业务场景中，大部分请求都集中在少数数据上（比如微博的热搜、电商的爆款商品），那么allkeys-lru是你的首选，它能精准地保住这些“明星”数据。 如果你的数据访问非常均匀，比如你是按时间顺序或ID顺序轮询查询不同数据，没有明显热点，那么allkeys-random可能更合适，避免了LRU的管理开销。

第三步：你的数据是不是“快消品”？ 如果你的数据都有明确的失效时间，并且你希望系统能自动按照失效顺序来优化空间，那么volatile-ttl会非常高效，它能让你缓存空间的内存利用率达到最高，因为总是优先清理“即将自然死亡”的数据。

一些实战中的小贴士：

• 监控是关键： 不要设完策略就不管了，一定要监控Redis的内存使用率（used_memory）和键空间命中率（keyspace_hits），如果命中率持续很低，说明淘汰策略可能不合适，或者你的缓存容量根本不够，大量请求都直接打到数据库了。
• 容量规划是根本： 再好的淘汰策略也只是“缓兵之计”，最根本的还是要根据业务量合理设置缓存的内存大小，不能让缓存长期处于“撑满”的状态，那样淘汰会非常频繁，影响性能，要留有一定的缓冲空间。
• 混合策略的思考： 有时候你的业务可能很复杂，单一策略不够用，比如既有需要永久保存的基础数据，又有访问热点明显的临时数据，还有生命周期固定的数据，这时候，你可能需要考虑使用volatile-lru，并精心设计不同数据的过期时间，或者甚至部署多个Redis实例，针对不同类型的数据采用不同的淘汰策略。

选择Redis淘汰策略没有银弹,它不是一个技术选择题，而是一个业务分析题，花点时间分析你的数据特性和访问模式，比盲目选择一种策略要有效得多，从最常用的allkeys-lru开始尝试，结合监控数据不断调整，才是通往“有效”缓存的正道。