*使用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>命令在生产环境上试验各种不同的采样大小值是很简单的。