Redis里那个最少用的缓存策略咋用才有效，LRU到底怎么帮缓存性能提升的讲解

关于Redis里最少使用的缓存策略怎么用才有效,以及LRU如何提升性能，我们得先从最基本的问题说起：缓存的空间是有限的，当缓存被数据塞满，再也装不下新东西的时候，怎么办？Redis必须决定把哪些旧数据踢出去，给新来的数据腾地方，这个“踢人”的规则，就是缓存淘汰策略，Redis提供了好几种策略，其中基于“最近最少使用”思想的LRU及其变种，是最经典也是最常用的。

LRU到底是什么？它怎么判断“最少使用”？

LRU,字面意思就是“最近最少使用”，它的核心思想非常直观：认为最近被访问过的数据，在接下来的一段时间内被再次访问的可能性更大；反之，很久都没被碰过的数据，将来被用的可能性就更低。 当需要淘汰数据时，那个最久没有被访问的“倒霉蛋”就应该被优先淘汰。

Redis是怎么知道哪个数据是“最久没被用”的呢？它不可能记住每个数据每次被访问的精确时间点，那样成本太高了，Redis采用了一种更聪明也更高效的方法，在Redis的对象系统中，每个键值对对象内部都维护了一个名为“lru”的字段（可以理解为一个小标签），每当这个键被访问（比如执行了get命令），Redis就会把当前的时间戳（一个代表时间的数字）记录在这个lru字段里。

你可以想象一下,这就像给每个数据贴上了一张“最后使用时间”的便利贴，当缓存满了，Redis要清理空间时，它只需要把所有候选数据看一遍，找出那张便利贴上时间最早、最老旧的那个，把它扔掉就行了，这个过程，就是LRU策略的执行。

Redis里的LRU不是“完美”的，但更有效

你可能会想,每次都全局扫描所有数据找最老的那个，万一缓存里有几百万个键，这扫描一遍岂不是慢死了？没错，如果真这么干，性能开销会非常大，Redis采用了一种近似LRU的算法，在效果和性能之间取了个巧。

Redis的近似LRU（Approximate LRU）是这样工作的：当需要淘汰数据时，它并不会检查所有的键，而是随机抽取一小批键（比如5个、10个，这个数量可配置），然后从这一小批键里面，淘汰掉那个lru时间戳最小的（也就是最久没被访问的），你可以把它比作一场“抽签淘汰赛”：不是让所有人赛跑，而是随机抽几个人出来，让他们比一比谁最后被访问的时间最早，最早的那个就被淘汰。

这种抽样方式听起来有点随机,不够精确，可能会误伤一些其实不算“最老”的数据，但根据Redis作者和社区的测试，当抽取的样本数量达到一定规模（比如5个以上）时，这种近似算法的效果已经非常接近完美的LRU了，而性能开销却小了几个数量级。 这是一种典型的“用一点点准确性的损失，换取巨大的性能提升”的工程智慧，我们平时说Redis的LRU，指的就是这种高效且实用的近似LRU。

LRU到底是怎么帮缓存性能提升的？

LRU提升缓存性能的逻辑,主要体现在“命中率”这个核心指标上。

1. 提高缓存命中率：缓存存在的意义，就是避免频繁去读取背后更慢的数据源（比如数据库），一次缓存查找就能找到数据，叫“命中”；没找到，得去查数据库，再塞回缓存，叫“缺失”，命中率越高，说明缓存发挥的作用越大，系统整体性能越好，LRU策略通过保留“最近热门”的数据，无情淘汰“长期冷门”的数据，使得有限的缓存空间里尽可能地装满最有可能被再次访问的数据，这就好比一个图书馆，总是把最常被借阅的书放在最显眼、最容易拿到的地方，而把无人问津的书挪到仓库里，这样大多数读者都能快速找到想看的书，整体借阅效率就高了。

2. 降低访问延迟：因为命中率提高了，更多的请求可以直接从速度极快的内存（Redis）中得到响应，避免了耗时得多的磁盘I/O或网络请求（访问数据库），这直接带来了更低的响应时间，用户体验更好。

3. 减轻后端压力：高命中率意味着到达后端数据库的请求数量显著减少，这不仅能防止数据库在流量高峰时被压垮，也为数据库节省了宝贵的计算资源，让它能更专注地处理必要的复杂查询和写入操作。

   

怎么用Redis的LRU策略才更有效？

光知道原理不行,用对地方才是关键。

1. 正确配置策略：在Redis的配置文件redis.conf中，找到maxmemory-policy这个配置项，你要使用LRU，就需要把它设置成allkeys-lru或volatile-lru。

   • allkeys-lru：这是最常用的策略，它会从所有键中（不管是否设置了过期时间）淘汰最近最少使用的，如果你的应用场景是希望缓存能自动管理，把所有数据都当做可淘汰的候选，就用这个。
   • volatile-lru：它只从设置了过期时间的键中淘汰最近最少使用的，这适用于你明确知道有些关键数据（比如用户基础信息）绝对不能丢，所以不给它们设过期时间，让它们永驻缓存；而其他一些可再生的数据（比如排行榜、热点文章）则设上过期时间并参与LRU淘汰。

2. 合理设置缓存大小：这是最关键的一步。maxmemory参数决定了Redis最多能用多少内存，这个值设得太小，缓存空间严重不足，会导致频繁的淘汰，命中率上不去；设得太大，又浪费内存资源，甚至可能影响系统其他部分，你需要根据你的业务数据量、访问模式和可用的服务器内存，找到一个平衡点，通常需要结合监控，观察缓存命中率和内存使用情况来不断调整优化。

3. 理解数据访问模式：LRU并不是万能的灵丹妙药，它最适合的是具有“局部热点”的访问模式，即一小部分数据在短时间内被反复访问（比如新闻网站的头条、电商的热销商品），如果你的数据访问是非常均匀的，或者是有循环顺序的，LRU的效果可能就不那么明显了，甚至可能不如FIFO（先进先出）或LFU（最不经常使用）策略，这就需要你对业务有深入的了解。

总结一下：Redis的LRU通过跟踪数据的最近访问时间，智能地淘汰掉最“冷”的数据，从而让宝贵的缓存空间留给最“热”的数据，最终达到提高缓存命中率、降低延迟、保护后端数据库的目的，要想让它发挥最大效力，关键在于根据你的业务特点，正确配置淘汰策略（allkeys-lru或volatile-lru）并精心设置合理的缓存大小（maxmemory），它不是一个“设完就忘”的开关，而是一个需要结合监控和业务理解进行持续调优的强大工具。

（参考资料：Redis官方文档关于Eviction policies的章节、《Redis设计与实现》一书中关于数据库与持久化的讲解）