前言
当Redis被当做缓存来使用，当你新增数据时，如果达到了最大可用内存，让它自动地回收旧数据是件很方便的事情。
LRU是Redis唯一支持的回收方法。
最大可用内存配置
maxmemory配置指令用于配置Redis存储数据时指定限制的内存大小。通过redis.conf可以设置该指令，或者之后使用CONFIG SET命令来进行运行时配置。
例如为了配置内存限制为100mb，以下的指令可以放在redis.conf文件中。
1 | maxmemory 100mb |
设置maxmemory为0代表没有内存限制。对于64位的系统这是个默认值，对于32位的系统默认内存限制为3GB。
当指定的内存限制大小达到时，需要选择不同的行为，也就是策略。 Redis可以仅仅对命令返回错误，这将使得内存被使用得更多，或者回收一些旧的数据来使得添加数据时可以避免内存限制。
达到最大可用内存时的回收策略
当maxmemory限制达到的时候Redis会使用的行为由 Redis的maxmemory-policy配置指令来进行配置。
Redis提供了下面几种淘汰策略供用户选择，其中默认的策略为noeviction策略：
- noeviction：当内存使用达到阈值的时候，所有引起申请内存的命令会报错。
- allkeys-lru：在主键空间中，优先移除最近未使用的key。
- allkeys-random：在主键空间中，随机移除某个key。
- volatile-lru：在设置了过期时间的键空间中，优先移除最近未使用的key。
- volatile-random：在设置了过期时间的键空间中，随机移除某个key。
- volatile-ttl：在设置了过期时间的键空间中，具有更早过期时间的key优先移除。
这里补充一下主键空间和设置了过期时间的键空间，举个例子，假设我们有一批键存储在Redis中，则有那么一个哈希表用于存储这批键及其值，如果这批键中有一部分设置了过期时间，那么这批键还会被存储到另外一个哈希表中，这个哈希表中的值对应的是键被设置的过期时间。设置了过期时间的键空间为主键空间的子集。
如果没有键满足回收的前提条件的话，策略volatile-lru, volatile-random以及volatile-ttl就和noeviction 差不多了。
我们了解了Redis大概提供了这么几种淘汰策略，那么如何选择呢？淘汰策略的选择可以通过下面的配置指定：
1 | # maxmemory-policy noeviction |
但是这个值填什么呢？为解决这个问题，我们需要了解我们的应用请求对于Redis中存储的数据集的访问方式以及我们的诉求是什么。同时Redis也支持Runtime修改淘汰策略，这使得我们不需要重启Redis实例而实时的调整内存淘汰策略。
下面看看几种策略的适用场景：
- allkeys-lru：如果我们的应用对缓存的访问符合幂律分布（也就是存在相对热点数据），或者我们不太清楚我们应用的缓存访问分布状况，我们可以选择allkeys-lru策略。
- allkeys-random：如果我们的应用对于缓存key的访问概率相等，则可以使用这个策略。
- volatile-ttl：这种策略使得我们可以向Redis提示哪些key更适合被eviction。
- volatile-lru和volatile-random策略适合我们将一个Redis实例既应用于缓存和又应用于持久化存储的时候，然而我们也可以通过使用两个Redis实例来达到相同的效果，值得一提的是将key设置过期时间实际上会消耗更多的内存，因此我们建议使用allkeys-lru策略从而更有效率的使用内存。
近似LRU算法
Redis的LRU算法并非完整的实现。这意味着Redis并没办法选择最佳候选来进行回收，也就是最久未被访问的键。相反它会尝试运行一个近似LRU的算法，通过对少量keys进行取样，然后回收其中一个最好的key（被访问时间较早的）。
不过从Redis 3.0算法已经改进为回收键的候选池子。这改善了算法的性能，使得更加近似真是的LRU算法的行为。
Redis LRU有个很重要的点，你通过调整每次回收时检查的采样数量，以实现调整算法的精度。这个参数可以通过以下的配置指令调整:
1 | maxmemory-samples 5 |
Redis为什么不使用真实的LRU实现是因为这需要太多的内存。不过近似的LRU算法对于应用而言应该是等价的。
以上配置为5，为默认配置，即Redis将检查五个键并选择一个最近使较少。
默认值为5会产生足够好的结果， 10近似非常接近，真正的LRU但花费更多的CPU，3非常快，但不是很准确。