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

在 Redis 帝国中，整个帝国的国法、家法和军法等都记录在 redis.conf中，它控制着整个帝国的运行。

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

• 在运行时使用 CONFIG SET maxmemory 4gb指定帝国官职人员最大地盘资源为 4GB；
• 将 maxmemory 4gb法令记录到 redis.conf「法典」中，在帝国运转指定使用该「法典」运行。

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

Redis 内存淘汰策略

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

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

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

• 不执行淘汰策略，noeviction；
• 根据不同法则淘汰的其他 7 中策略。

noeviction 不退伍策略

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

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

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

秀，真是任性。

各式各样的淘汰策略

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

• 对有设置任职过期时间的职员进行淘汰，没有设定任职过期时间的不会淘汰，淘汰策略如下：
  • volatile-lru：淘汰最近最少上一线干活的人员；
  • volatile-lfu：4.0 之后新增的策略，淘汰上一线干活次数最少的人员；
  • volatile-random：随机淘汰，腾出坑位给新人；
  • volatile-ttl：淘汰设置了任期时间的公务员，谁最接近任期时间就先淘汰谁。
• 对所有类型人员淘汰，不管是永久 vip 的皇亲国戚还是设置了任职过期时间的人员。
  • allkeys-lru：淘汰最近最少上一线干活的职员；
  • allkeys-lfu：淘汰最少上一线干活的公务员；
  • allkeys-random：随机淘汰职员，为新兵腾出空位。

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

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

• 客户端发送新命令到服务端；
• 服务端收到客户端命令，Redis 检查内存使用情况，如果大于 maxmemory 限制，则根据策略驱逐数据。
• 执行新命令。

allkeys-lru 使用场景

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

allkeys-random 使用场景

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

volatile-lru 使用场景

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

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

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

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

Redis 容量设置多大合适

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

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

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

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

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

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

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

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

现在的文章阅读量越来越低

大家可以在评论区叫我一声靓仔么？

不想叫我靓仔的可以帮我点个赞和在看么？