Redis内存淘汰机制

Redis过期策略以及内存淘汰机制
过期键删除策略
定时删除
设置键的过期时间时，创建一个 Timer ，当过期时间到临时，立刻删除键。
内存友好型策略，一旦键过期，就会被删除，并释放所占用的内存，Cpu 不友好，当一批数量比较多的键过期时，正好遇上Cpu 紧张的时段，这时候需要的是Cpu处理能力，而不是内存，显然 Cpu 时间用在删除过期键上，会对服务器的响应时间和吞吐量造成影响。另外当前 Redis 时间事件（无序链表O(N)）无法高效处理大量时间事件，所以定时删除并不是一种好的定时删除策略。
惰性删除
不管过期的键，在这种策略下，当键在键空间中被取出时，首先检查取出的键是否过期，若过期删除该键，否则，返回该键。
很明显，惰性删除依赖过期键的被动访问，对于内存不友好，如果一些键长期没有被访问，会造成内存泄露（垃圾数据占用内存）。我们知道，Redis是依赖内存的，所以惰性删除也不是一个好的策略。
定期删除
由定时删除算法，定期的去检查一定的数据库，删除一定的过期键。
通过合理的删除操作执行的时长和频率，达到合理的删除过期键。

redis.conf 中的内存淘汰机制
看下 Redis 源码中的默认配置

MAXMEMORY POLICY: how Redis will select what to remove when maxmemory

is reached. You can select among five behaviors:

#最大内存策略：当到达最大使用内存时，你可以在下面5种行为中选择，Redis如何选择淘汰数据库键

#当内存不足以容纳新写入数据时

volatile-lru -> remove the key with an expire set using an LRU algorithm

volatile-lru ：在设置了过期时间的键空间中，移除最近最少使用的key。这种情况一般是把 redis 既当缓存，又做持久化存储的时候才用。

allkeys-lru -> remove any key according to the LRU algorithm

allkeys-lru ： 移除最近最少使用的key （推荐）

volatile-random -> remove a random key with an expire set

volatile-random ： 在设置了过期时间的键空间中，随机移除一个键，不推荐

allkeys-random -> remove a random key, any key

allkeys-random ： 直接在键空间中随机移除一个键，弄啥叻

volatile-ttl -> remove the key with the nearest expire time (minor TTL)

volatile-ttl ： 在设置了过期时间的键空间中，有更早过期时间的key优先移除 不推荐

noeviction -> don’t expire at all, just return an error on write operations

noeviction ： 不做过键处理，只返回一个写操作错误。 不推荐

Note: with any of the above policies, Redis will return an error on write

operations, when there are no suitable keys for eviction.

上面所有的策略下，在没有合适的淘汰删除的键时，执行写操作时，Redis 会返回一个错误。下面是写入命令：

At the date of writing these commands are: set setnx setex append

incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd

sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby

zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby

getset mset msetnx exec sort

过期策略默认是：

The default is:

maxmemory-policy noeviction

其他模块对过期键的处理
生成RDB文件时
执行 SAVE 或 BGSAVE 时 ，数据库键空间中的过期键不会被保存在RDB文件中

载入RDB文件时
Master 载入RDB时，文件中的未过期的键会被正常载入，过期键则会被忽略。
Slave 载入 RDB 时，文件中的所有键都会被载入，当同步进行时，会和Master 保持一致。
AOF 文件写入时
数据库键空间的过期键的过期但并未被删除释放的状态会被正常记录到 AOF 文件中，当过期键发生释放删除时，DEL 也会被同步到 AOF 文件中去。

重新生成 AOF文件时
执行 BGREWRITEAOF 时 ，数据库键中过期的键不会被记录到 AOF 文件中

复制
Master 删除 过期 Key 之后，会向所有 Slave 服务器发送一个 DEL命令，从服务器收到之后，会删除这些 Key。
Slave 在被动的读取过期键时，不会做出操作，而是继续返回该键，只有当Master 发送 DEL 通知来，才会删除过期键，这是统一、中心化的键删除策略，保证主从服务器的数据一致性。