Redis关于内存的几个问题，是不是可以整合为GC（哪里有第一手资料）。很多文章不含reference。
这里仅做简单梳理，需要进一步完善深入。
第一部分 常用过期策略及优缺点
一、常用过期策略
0、定时删除
在设置key的过期时间的时候，给key设置一个定时器，到了指定时间就清除key。
1、惰性删除
key过期的时候不删除，下次访问该key的时候检查过期时间，过期就删除，返回null。
2、定期删除
每隔一段时间执行一次删除过期key的操作(设置执行时间)。
二、优缺点
0、定时删除优点，保证内存被尽快释放。对内存绝对友好。
1、定时删除缺点，为每个设置过期时间的key创建定时器，定时器数量多，影响性能；同时过期的key很多，很占有大量CPU时间。
2、惰性删除优点，对CPU占有比较少。对CPU绝对友好。
3、惰性删除缺点，过期key很久未访问，可能发生内存泄漏。
4、定期删除优点，限制删除的频率，对CPU占用相对少。
5、定期删除缺点，不是觉得对内存友好，也不是觉得对CPU友好。
第二部分 Redis过期策略
Redis采用惰性删除和定期删除相结合的策略。
一、设置过期时间
Redis对存储数据过期时间是针对key设置的。所以key的过期时间保存在字典Expires中。
0、指定key存活时间
expire, pexpire
1、指定key过期时间
pexpire
pexpireAt
二、过期流程
0、进行get, setnx时，检查key是否过期，过期就删除，返回null。没有过期正常执行。
1、遍历每个数据库，检查是否有设置过期时间的key，没有就跳过；有就随机获取一个key检查，过期就删除，删除操作到了指定时间就推出。
为什么不用定时删除策略?
定时删除,用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key,因此没有采用这一策略
定期删除+惰性删除是如何工作的呢?
定期删除，redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。
于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除
采用定期删除+惰性删除就没其他问题了么?
不是的，如果定期删除没删除key。然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。
三、持久化对过期key的处理
过期的key对RDB和AOF两种持久化方式都没有影响。
0、RDB方式的处理
导出：持久化之前会检查key是否过期，过期不进入RDB文件。(这个工作量不大嘛，不是简单的快照呀)
导入：从RDB文件恢复数据，检查key是否过期，过期不导入数据库。
1、AOF方式的处理
导出：key过期后，在删除的时候会追加del命令到AOF文件。
导入：从AOF文件重建数据的时候，检查key是否过期，过期不执行。
第三部分 Redis内存淘汰机制
当Redis用于缓存数据的内存不足时，如何淘汰数据，这就是Redis内存淘汰机制。
一、6种内存淘汰机制
0、noeviction
1、allkeys-lru
2、allkeys-random
3、volatile-lru
4、volatile-random
5、volatile-ttl
volatile-lru ：采用LRU算法(最近最少使用算法)，但是只淘汰超时的键值对。
allkeys-lru ：采用LRU算法，淘汰键值对。
volatile-random :采用随机淘汰策略，但是只淘汰超时的键值对。
allkeys-random :采用随机淘汰策略，淘汰键值对。
volatile-ttl ：采用TTL算法(生存周期)，淘汰存活时间最短的键值对。
noeviction ：不淘汰任何键值对，内存已满时，进行写操作返回错误。
注：当存储用，选择noeviction。当缓存用如果不清楚如何选择，选择allkeys-lru即可。
之前在微博创造营活动中，遇到一次投票后写入redis失败的情况，是内存满了。参考《新浪微博NoSQL应用笔记》
二、内存淘汰机制的设置
# maxmemory <bytes> 配置内存阈值 # maxmemory-policy noeviction
第四部分 Redis引用计数
参考
Redis过期删除策略和定期删除策略区别
Redis学习笔记–Redis数据过期策略详解
Redis的过期策略和内存淘汰策略
Redis的内存回收机制