配置Redis作为缓存（六种淘汰策略）
将Redis用做缓存时，如果内存空间用满，就会自动驱逐老的数据。
LRU是Redis唯一支持的回收算法，本文详细介绍用于限制最大内存使用量的
maxmemory指令，并深入讲解Redis所使用的近似LRU算法。
maxmemory配置指令
maxmemory用于Redis能使用的最大内存。既可以在redis.conf文件中设置，
也可以再运行过程中通过config set命令动态修改。
例如，要设置100MB的内存限制，可以在redis.conf文件中这样配置：
maxmemory 100mb
将maxmemory设置为0，则表示不进行内存限制，当然，对32位系统来说有一个隐性的限制条件：最多3GB内存。
当内存使用达到最大限制时，如果需要存储新数据，根据配置的策略（policies）的不同，Redis可能直接返回错误信息，
或者删除部分老的数据。
驱逐策略
达到最大内存限制时（maxmemory），Redis根据maxmemory-policy配置的策略，来决定具体的行为。
当前版本，Redis3.0支持的策略包括：
noeviction:不删除策略，达到最大内存限制时，如果需要更多内存，直接返回错误信息。
大多数写命令都会导致占用更多的内存（有极少数例外，如del）
allkeys-lru:所有key通用，优先删除最近最少使用的(less recently used,LRU)key.
allkeys-random:所有key通用，随机删除一部分key.
volatile-random:只限于设置了expire的部分，删除一部分expire的key.
volatile-ttl:只限于设置了expire的部分，优先删除剩余时间(time to live,TTL)短的key.
如果没有设置expire的key,不满足先决条件（prerequisites）,那么volatile-lru,volatile-random和volatile-ttl策略的行为，
和noeviction（不删除策略）基本上一致。
一般来说：
如果分为热数据和冷数据，推荐使用allkeys-lru策略，也就是，其中一部分key经常被读写，如果不确定具体的业务特征，
那么allkeys-lru是一个很好的选择。
如果需要循环读写所有的key,或者各个key的访问频率差不多，可以使用allkeys-random策略，即读写所有的元素的概率差不多。
假如要让Redis根据ttl来筛选需要删除的key,请使用volatile-ttl策略。
volatile-lru和volatile-random策略主要应用场景是：既有缓存，又有持久key的实例中，一般来说，像这类场景，应该使用两个单独的Redis实例。
值得一提的是，设置expire会消耗额外的内存，所以使用allkeys-lru策略，可以更高效的利用内存，因为这样就可以不再设置过期时间了。
驱逐的内部实现
驱逐过程可以这样理解：
1、客户端执行一个命令，导致Redis中的数据增加，占用更多的内存。
2、Redis检查内存使用量，如果超出maxmemory限制，根据策略清除部分key.
3、继续执行下一条命令，以此类推。
在这个过程中，内存使用量会不断的达到limit值，然后超过，然后删除部分key,使用量又下降到limit值之下。
如果某个命令导致大量内存使用（比如通过新key保存一个很大的set）,在一段时间内，可能内存的使用量会明显超过maxmemory限制。
近似LRU算法
Redis使用的并不是完全LRU算法，自动驱逐的key,并不一定是最满足LRU特征的那个，而是通过近似LRU算法，
抽取少量的key样本，然后删除其中访问时间最古老的那个key.
驱逐算法，从Redis3.0开始得到了巨大的优化，使用pool(池子)来作为候选，
这大大提升了算法的效率，也更接近真实的LRU算法。
测试过程中, 依次从第一个 key 开始访问, 所以最前面的 key 才是最佳的驱逐对象。
从图中可以看到三种类型的点, 构成了三个不同的条带。
浅灰色部分表示被驱逐的对象。
灰色部分表示 “未被驱逐” 的对象。
绿色部分表示后面加入的对象。
在纯粹的LRU算法实现中, 前半部分旧的key被释放了。而 Redis 的 LRU 算法只是将时间较长的 key 较大概率地(probabilistically)释放了。
如你所见, Redis 3.0 中, 5样本的效果比 Redis 2.8 要好很多。 当然, Redis 2.8 也不错,最后访问的key基本上都还留在内存中. 在 Redis 3.0 中使用 10 样本时, 已经非常接近纯粹的LRU算法了。
注意,LRU只是用来预测将来可能会继续访问某个key的一个概率模型. 此外,如果数据访问的情况符合幂律分布(power law), 那么对于大部分的请求来说, LRU都会表现良好。
在模拟中, 我们发现, 如果使用幂律方式访问, 纯粹的LRU和Redis的结果差别非常, 甚至看不出来。
当然也可以将样本数量提高到10, 以额外消耗一些CPU为代价, 使得结果更接近于真实的LRU, 并通过 cache miss 统计信息来判断差异。
设置样本大小很容易, 使用命令 CONFIG SET maxmemory-samples <count> 即可。