Redis 内存满了怎么办？这样设置才正确！-创站工坊

Redis 内存满了怎么办？这样设置才正确！

发布时间：2025-11-05 02:38:45 来源：创站工坊作者：应用开发

上回在《Redis 数据过期了会被立马删除么?存满才正》说到如果过期的数据太多，定时删除无法删除完全(每次删除完过期的办样 key 还是超过 25%)，同时这些 key 再也不会被客户端请求，设置就无法走惰性删除，存满才正内存被打满会怎样?办样

答案是走内存淘汰机制。

故事从一个叫 Redis 帝国的设置三公九卿官职说起……

在 Redis 帝国中，整个帝国的存满才正国法、家法和军法等都记录在 redis.conf中，办样它控制着整个帝国的设置运行。

公务员占用的存满才正国家地盘资源大小限定由名叫「maxmemory」的司法官员制定，一共有两种方式实现：

需要注意的存满才正是，如果 maxmemory 为 0 ，办样在 64 位「空间」上则没有限制，设置而 32 位「空间」则有 3GB 的隐式限制。

设置了帝国官职地盘资源限制，每年选拔新人就会导致没有地盘资源可以使用怎么办?如何选择一些公务员淘汰?

在 Redis 4.0 时代，一共有 6 种淘汰策略，之后，又新增了 2 种策略。

总体上我们可以根据是服务器托管否需要淘汰可以分为两大类：

默认情况下，资源超过 maxmemory 的值也不会执行淘汰，不允许新人加入。

关系户啊这是，皇亲国戚，永久 vip 啊喂。

随着官职人员的新增，由于不会淘汰，资源容量迟早会满。满了以后，当有「新人」想要进来的时候，Redis 直接返回错误，并罢工。

秀，真是任性。

剩下的 7 种策略还可以根据淘汰的候选集合和淘汰范围分为两大类：

volatile-lru：淘汰最近最少上一线干活的人员;

volatile-lfu：4.0 之后新增的策略，云服务器提供商淘汰上一线干活次数最少的人员;

volatile-random：随机淘汰，腾出坑位给新人;

volatile-ttl：淘汰设置了任期时间的公务员，谁最接近任期时间就先淘汰谁。

allkeys-lru：淘汰最近最少上一线干活的职员;

allkeys-lfu：淘汰最少上一线干活的公务员;

allkeys-random：随机淘汰职员，为新兵腾出空位。

故事到这里就结束了，接下来「码哥」分享下在实际 Redis 中如何选择合适的淘汰策略和设置最佳缓存大小给大家。

淘汰执行过程如下图所示：

redis-eviction

假如你的应用存在明显的冷热数据区别，根据经验推荐你使用这个策略，充分利用 LRU 算法把最近最常访问的数据保留，有限的内存提高访问性能。

假如数据没有明显的冷热分别，高防服务器所有的数据分布查询比较均衡，这些数据都会被随机查询，那就使用 allkeys-random 策略，让其随机选择淘汰数据。

业务场景有一些数据不能删除，比如置顶新闻、视频，这时候我们为这些数据不设置过期时间，这样的话数据就不会被删除，该策略就会去根据 LRU 算法去淘汰那些设置了过期时间且最近最少被访问的数据。

有一个点需要注意下，为 key 执行 expire 设置过期时间会消耗一些内存，所以使用 allkeyds-lru 会提高内存效率。

将需要持数据不能删除的和全都可以淘汰数据的业务系统分别使用不同的 Redis 实例集群是更好的方案。

针对业务场景有一些数据不能删除的使用 volatile-lru策略，另一类则可以使用 allkyes-lru 或者 allkeys-random。

缓存并不是越大越好，用最小的代价去获得最高的收益才是老板想要的。

数据访问有局部性，根据「二八原理」：通常 20% 的数据能支撑 80% 的访问请求。

所以我们可不可以把缓存容量大小设置为总数据量的 20%?

当然，不能这么绝对，这是理想状态。因为可能存在一些个性化需求，不同的用户访问的数据可能差别很大，不完全具备「二八原理」。

我们应当结合实际的访问特点和成本来综合评估。根据经验建议将容量设置成总数据量的 15%~30%。

码哥，其他淘汰规则比较简单，volatile-lru 和 volatile-lfu 则比较复杂，他们的算法是怎样的?

volatile-lru 使用了 LRU 算法，淘汰最近最少使用的数据。而 volatile-lfu 使用了 LFU 算法，它在 LRU 算法基础上同时考虑了数据的时效性和访问频率，最少访问的 key 会被删除。

至于具体算法细节，我们下回分解。一次性太多的话大家容易在知识的海洋里里呛水。

随便看看