4. 淘汰策略
4.1 过期键删除
4.1.1 过期策略
在《1.1 redisObject》章节中我们看到“lru:LRU_BITS”字段记录了一个24bits的时间信息，当我们给一个Key设置过期时间的时候就会在这个地方记录上时间信息，那么当这个Key过期了，它会什么时候被删除呢？
可以想到的有三种删除方案：
- 定时删除：设置键的过期时间的同时，创建一个定时器，然后在键过期的时候触发删除操作。
- 惰性删除：在获取键的时候，检查键是否过期，如果过期的话，执行删除操作。
- 定期删除：每隔一段时间，检查数据库中的键是否过期，如果过期的话，执行删除操作。
而Redis考虑CPU和内存空间的平衡采用了惰性删除和定期删除。
惰性删除很好理解，在每次访问到一个带有过期时间的Key时，都检查一下这个key的时间是否过期，如果过期则将这个数据删除并返回空，如果未过期则执行实际的命令流程。但是有个问题，当一个Key被访问一次后，再也不被访问了，那岂不是这个Key永远存在了Redis里？所以，除了惰性删除，Redis还加了定期删除策略，默认100ms执行一次过期检测，从设置了过期键的dict里抽出一定数据（默认20个），删除已过期的数据，如果有大于25%的数据过期，则重复执行。
乍看好像定期删除这个策略毫无破绽，但是我们思考一个特殊的场景：Redis库里大量的Key都在同一个时间过期，这时调起了定期删除任务，第一次执行完之后发现超过25%的数据过期，又调起第二次定期删除任务......一直循环直到某次删除的过期数据小于25%，Redis服务器才开始执行别的任务，这对于Redis来说就很可能造成服务不可用，引发一次严重的线上事故！所以当我们在设置过期时间的时候一定要注意，避免大量Key被设置到同一时间过期，而是平滑地将Key的过期时间分布在不同的时间段内。
4.1.2 从节点的过期策略
Redis的从节点不会删除过期Key，只会通过主节点同步的del指令来删除这个key（主从模式下，主节点在删除过期Key时会在AOF文件中显性写入一条del命令同步给从节点）。值得注意的是，在Redis 3.2版本之前，如果一个键已经过期了，并且主节点并未删除这个数据，那么你可以在从节点继续正常访问这个Key。
在Redis 3.2-rc1版本中，Redis加入了一个新特性来解决主从不一致导致读取到过期数据的问题（好吧，虽然这个新特性我们一直觉得是个bug fix），在源码db.c文件中，作者对lookupKeyReadWithFlags（读命令）做了相应的修改，增加了key是否过期以及对主从库的判断（代码如下），如果key已过期，当前访问的是master则返回null；当前访问的是从库，且执行的是只读命令也返回null（老版本从库真实的返回该操作的结果，如果该key过期后主库没有删除），源码如下：
robj *lookupKeyReadWithFlags(redisDb *db, robj *key, int flags) {
robj *val;
if (expireIfNeeded(db,key) == 1) {
/* Key expired. If we are in the context of a master, expireIfNeeded()
* returns 0 only when the key does not exist at all, so it's safe
* to return NULL ASAP. */
if (server.masterhost == NULL) {
server.stat_keyspace_misses++;
notifyKeyspaceEvent(NOTIFY_KEY_MISS, "keymiss", key, db->id);
return NULL;
}
/* However if we are in the context of a slave, expireIfNeeded() will
* not really try to expire the key, it only returns information
* about the "logical" status of the key: key expiring is up to the
* master in order to have a consistent view of master's data set.
*
* However, if the command caller is not the master, and as additional
* safety measure, the command invoked is a read-only command, we can
* safely return NULL here, and provide a more consistent behavior
* to clients accessign expired values in a read-only fashion, that
* will say the key as non existing.
*
* Notably this covers GETs when slaves are used to scale reads. */
if (server.current_client &&
server.current_client != server.master &&
server.current_client->cmd &&
server.current_client->cmd->flags & CMD_READONLY)
{
server.stat_keyspace_misses++;
notifyKeyspaceEvent(NOTIFY_KEY_MISS, "keymiss", key, db->id);
return NULL;
}
}
val = lookupKey(db,key,flags);
if (val == NULL) {
server.stat_keyspace_misses++;
notifyKeyspaceEvent(NOTIFY_KEY_MISS, "keymiss", key, db->id);
}
else
server.stat_keyspace_hits++;
return val;
}
4.2 异步删除
我们常用的删除命令del，正常情况下使用这个命令我们不会有任何感知，它也会立即释放对象的内存。但是当我们del一个非常大的对象时，这时就会造成主线程卡顿，引起服务延迟。
所以在Redis4.0之后，作者引入了另一个删除命令：unlink，就如这个名字一样，它实际做的事情是断开连接。就比如我们有一串葡萄，unlink做的事情就是将其中一颗摘下来。内部实现来说，unlink其实是对删除操作进行懒处理，将对象丢给后台线程来异步回收内存，这样主线程就能继续对外提供服务了。
当然除了unlink命令，还有flushdb、flushall、Key的过期、LRU淘汰、rename指令过程中，也会实施回收内存，这些想要异步删除就需要额外的一些操作。
- 手动执行flushdb/flushall时想要异步删除，需要在后面加个async
- slave-lazy-flush：从节点接受完rdb文件后的flush操作
- lazyfree-lazy-eviction：内存达到maxmemory时进行删除
- lazyfree-lazy-expire key：过期删除
- lazyfree-lazy-server-del rename：指令删除destKey
4.3 内存超出策略
当实际内存超出maxmemory时，Redis 提供了几种可选策略( maxmemory-policy)来让用户自己决定该如何腾出新的空间以继续提供读写服务。
- noeviction：不会继续服务写请求(del 请求可以继续服务)，读请求可以继续进行。这样可以保证不会丢失数据，但是会让线上的业务不能持续进行。这是默认的淘汰策略。
- volatile-lru：尝试淘汰设置了过期时间的key, 最少使用的key优先被淘汰。没有设置过期时间的key不会被淘汰，这样可以保证需要持久化的数据不会突然丢失。
- volatile-ttl：跟上面几乎一样，不过淘汰的策略不是LRU, 而是比较key的剩余寿命ttl的值，ttl 越小越优先被淘汰。
- volatile-random： 跟上面几乎一样， 不过淘汰的key是过期key集合中随机的key。
- allkeys-lru：区别于volaile-ru, 这个策略要淘汰的key对象是全体的key集合，而不只是过期的key集合。这意味着一些没有设 置过期时间的key也会被淘汰。
- allkeys-random：跟上面几乎样，不过淘汰的key是随机的key.
volatile-xxx策略只会针对带过期时间的key进行淘汰，allkeys-xxx策略会对所有的key进行淘汰。如果你只是拿Redis做缓存，那么应该使用allkeys-xxx策略，客户端写缓存时不必携带过期时间。如果你还想同时使用Redis的持久化功能，那就使用volatile-xxx策略，这样可以保留没有设置过期时间的key，它们是永久的key, 不会被LRU算法淘汰。
注意：Redis4.0之后，又添加了2个选项，分别是volatile-lfu和allkeys-lfu。逻辑和前面的配置几乎相同，只是将算法换成了LFU
