*使用Redis作为LRU缓存

如果你使用redis作为缓存，当添加新数据时，若有内存大小等限制，系统默认会根据一定的规则自动清理旧数据。这种处理方式在开发社区中众所周知，因为它也是非常流行的缓存系统 memcached 的默认处理方式。

LRU（LRU全称是Least Recently Used，即最近最久未使用）实际上只是Redis支持的内存回收策略中的一种。这篇文章将要讲述Redis的 maxmemory 配置选项，该配置选项用来限制 Redis 的内存使用大小，同时深入研究 LRU（确切的说是近似LRU算法） 算法在 Redis 中的应用。

*最大内存配置选项

maxmemory 配置选项使用来配置 Redis 的存储数据所能使用的最大内存限制。可以通过在内置文件redis.conf中配置，也可在Redis运行时通过命令CONFIG SET来配置。例如，我们要配置内存上限是100M的Redis缓存，那么我们可以在 redis.conf 配置如下：

maxmemory 100mb

设置 maxmemory 为 0 表示没有内存限制。在 64-bit 系统中，默认是 0 无限制，但是在 32-bit 系统中默认是 3GB。

当存储数据达到限制时，Redis 会根据情形选择不同策略，或者返回errors（这样会导致浪费更多的内存），或者清除一些旧数据回收内存来添加新数据。

*回收策略

当内存达到限制时，Redis 具体的回收策略是通过 maxmemory-policy 配置项配置的。

以下的策略都是可用的：

  • noenviction：不清除数据，只是返回错误，这样会导致浪费掉更多的内存，对大多数写命令（DEL 命令和其他的少数命令例外）
  • allkeys-lru：从所有的数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰，以供新数据使用
  • volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰，以供新数据使用
  • allkeys-random：从所有数据集（server.db[i].dict）中任意选择数据淘汰，以供新数据使用
  • volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰，以供新数据使用
  • volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰，以供新数据使用

当 cache 中没有符合清除条件的 key 时，回收策略 volatile-lru, volatile-random 和volatile-ttl 将会和 策略 noeviction 一样返回错误。选择正确的回收策略是很重要的，取决于你的应用程序的访问模式。但是，你可以在程序运行时重新配置策略，使用 INFO 输出来监控缓存命中和错过的次数，以调优你的设置。

普适经验规则：

  • 如果期望用户请求呈现幂律分布(power-law distribution)，也就是，期望一部分子集元素被访问得远比其他元素多时，可以使用allkeys-lru策略。在你不确定时这是一个好的选择。
  • 如果期望是循环周期的访问，所有的键被连续扫描，或者期望请求符合平均分布(每个元素以相同的概率被访问)，可以使用allkeys-random策略。
  • 如果你期望能让 Redis 通过使用你创建缓存对象的时候设置的TTL值，确定哪些对象应该是较好的清除候选项，可以使用volatile-ttl策略。

当你想使用单个Redis实例来实现缓存和持久化一些键，allkeys-lru和volatile-random策略会很有用。但是，通常最好是运行两个Redis实例来解决这个问题。

另外值得注意的是，为键设置过期时间需要消耗内存，所以使用像allkeys-lru这样的策略会更高效，因为在内存压力下没有必要为键的回收设置过期时间。

*回收过程

理解回收过程是运作流程非常的重要，回收过程如下：

  • 一个客户端运行一个新命令，添加了新数据。
  • Redis检查内存使用情况，如果大于maxmemory限制，根据策略来回收键。
  • 一个新的命令被执行，如此等等。

我们添加数据时通过检查，然后回收键以返回到限制以下，来连续不断的穿越内存限制的边界。

如果一个命令导致大量的内存被占用(比如一个很大的集合保存到一个新的键)，那么内存限制很快就会被这个明显的内存量所超越。

*近似LRU算法

Redis的LRU算法不是一个严格的LRU实现。这意味着Redis不能选择最佳候选键来回收，也就是最久未被访问的那些键。相反，Redis 会尝试执行一个近似的LRU算法，通过采样一小部分键，然后在采样键中回收最适合(拥有最久访问时间)的那个。

然而，从Redis3.0开始，算法被改进为维护一个回收候选键池。这改善了算法的性能，使得更接近于真实的LRU算法的行为。Redis的LRU算法有一点很重要，你可以调整算法的精度，通过改变每次回收时检查的采样数量。

这个参数可以通过如下配置指令：

maxmemory-samples 5

Redis没有使用真实的LRU实现的原因，是因为这会消耗更多的内存。然而，近似值对使用Redis的应用来说基本上也是等价的。下面的图形对比，为Redis使用的LRU近似值和真实LRU之间的比较。

687474703a2f2f72656469732e696f2f696d616765732f7265646973646f632f6c72755f636f6d70617269736f6e2e706e67{.alignnone .size-full .wp-image-996 width="854" height="449"}

用于测试生成了上面图像的Redis服务被填充了指定数量的键。键被从头访问到尾，所以第一个键是LRU算法的最佳候选回收键。然后，再新添加50%的键，强制一般的旧键被回收。

你可以从图中看到三种不同的原点，形成三个不同的带。

  • 浅灰色带是被回收的对象
  • 灰色带是没有被回收的对象
  • 绿色带是被添加的对象

在理论的LRU实现中，我们期望看到的是，在旧键中第一半会过期。而Redis的LRU算法则只是概率性的过期这些旧键。 你可以看到，同样使用5个采样点，Redis 3.0表现得比Redis 2.8要好，Redis 2.8中最近被访问的对象之间的对象仍然被保留。在Redis 3.0中使用10为采样大小，近似值已经非常接近理论性能。

注意，LRU只是一个预测模型用来指定键在未来如何被访问。另外，如果你的数据访问模式非常接近幂律，大多数的访问都将集中在一个集合中，LRU近似算法将能处理得很好。

在模拟实验的过程中，我们发现使用幂律访问模式，真实的LRU算法和Redis的近似算法之间的差异非常小，或者根本就没有。然而，你可以提高采样大小到10，这会消耗额外的CPU，来更加近似于真实的LRU算法，看看这会不会使你的缓存错失率有差异。

使用CONFIG SET maxmemory-samples <count>命令在生产环境上试验各种不同的采样大小值是很简单的。