前提补充
我们讲过期策略之前，我们先来看几个问题，后面学习的时候带着这几个问题去学习。
我往redis里写的数据怎么没了？
我相信大家在使用redis的时候，都会遇到redis经常丢掉一些数据，写进去了，过一会儿可能就没了。那么这个问题我们需要反思一下：redis是缓存，你给当存储了是吧？
什么是缓存？用内存当缓存。内存是无限的吗，内存是很宝贵而且是有限的，磁盘是廉价而且是大量的。可能一台机器就几十个G的内存，但是可以有几个T的硬盘空间。redis主要是基于内存来进行高性能、高并发的读写操作的。
那既然内存是有限的，比如redis就只能用10个G，你要是往里面写了20个G的数据，会咋办？当然会干掉10个G的数据，然后就保留10个G的数据了。那干掉哪些数据？保留哪些数据？当然是干掉不常用的数据，保留常用的数据了。
所以说，这是缓存的一个最基本的概念，数据是会过期的，要么是你自己设置个过期时间，要么是redis自己给干掉了。
set key value 过期时间（1小时）
set进去的key，1小时之后就没了，就失效了
我的数据明明都过期了，怎么还占用着内存啊？
还有一种就是如果你设置好了一个过期时间，你知道redis是怎么给你弄成过期的吗？什么时候删除掉？如果你不知道，那么你就需要思考，为啥好多数据明明应该过期了，结果发现redis内存占用还是很高？那是因为你不知道redis是怎么删除那些过期key的。
redis内存一共是10g，你现在往里面写了5g的数据，结果这些数据明明你都设置了过期时间，要求这些数据1小时之后都会过期，结果1小时之后，你回来一看，redis机器，怎么内存占用还是50%呢？5g数据过期了，我从redis里查，是查不到了，结果过期的数据还占用着redis的内存。
如果你连这个问题都不知道，上来就懵了，回答不出来，那线上你写代码的时候，想当然的认为写进redis的数据就一定会存在，后面导致系统各种漏洞和bug，谁来负责？
对key设置过期时间
expire key time(以秒为单位)–这是最常用的方式
Redis对存储值的过期处理实际上是针对该值的键（key）处理的，即时间的设置也是设置key的有效时间。
Expires字典保存了所有键的过期时间，Expires也被称为过期字段。
注意：
1、除了字符串自己独有设置过期时间的方法外，其他方法都需要依靠expire方法来设置时间
2、如果没有设置时间，那缓存就是永不过期
3、如果设置了过期时间，之后又想让缓存永不过期，使用persist key
过期策略
三种过期策略机制
1）定时删除（没人用）
含义：在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除。
优点：可以保证内存被尽快释放
缺点：若过期key很多，删除这些key会占用很多的CPU时间，在CPU时间紧张的情况下，CPU不能把所有的时间用来做要紧的事儿，还需要去花时间删除这些key
2）惰性删除
含义：key过期的时候不删除，每次从redis获取key的时候去检查是否过期，若过期，则删除，返回null。
优点：删除操作只发生在从数据库取出key的时候发生，而且只删除当前key，所以对CPU时间的占用是比较少的，而且此时的删除是已经到了非做不可的地步（如果此时还不删除的话，我们就会获取到了已经过期的key了）
缺点：若大量的key在超出超时时间后，很久一段时间内，都没有被获取过，那么可能发生内存泄露（无用的垃圾占用了大量的内存）
3）定期删除
含义：所谓定期删除，指的是redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。
优点：通过限制删除操作的时长和频率，来减少删除操作对CPU时间的占用–处理”定时删除”的缺点
缺点：
在内存友好方面，不如”定时删除”
在CPU时间友好方面，不如”惰性删除”
定期删除过期key可以处理”惰性删除”的缺点
三种过期策略机制总结
看完上面三种策略后可以得出以下结论：
定时删除和定期删除为主动删除：Redis会定期主动淘汰一批已过去的key
惰性删除为被动删除：用到的时候才会去检验key是不是已过期，过期就删除。
定期删除可以通过：
第一、配置redis.conf的hz选项，默认为10 （即1秒执行10次，100ms一次，值越大说明刷新频率越快，最Redis性能损耗也越大）
第二、配置redis.conf的maxmemory最大值，当已用内存超过maxmemory限定时，就会触发主动清理策略
Redis默认采用的过期策略
Redis服务器默认过期内置策略是：惰性删除+定期删除
惰性删除流程：
在进行get或setnx等操作时，先检查key是否过期；
若过期，删除key，然后执行相应操作；
若没过期，直接执行相应操作。
定期删除流程：
（简单而言，对指定个数个库的每一个库随机删除小于等于指定个数个过期key）
遍历每个数据库（就是redis.conf中配置的”database”数量，默认为16）
检查当前库中的指定个数个key（默认是每个库检查20个key，注意相当于该循环执行20次，循环体时下边的描述）
如果当前库中没有一个key设置了过期时间，直接执行下一个库的遍历。
随机获取一个设置了过期时间的key，检查该key是否过期，如果过期，删除key。
判断定期删除操作是否已经达到指定时长，若已经达到，直接退出定期删除。
提问：为什么不使用定时删除，而使用定期删除呢？
所谓定期删除，指的是redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。假设redis里放了10万个key，都设置了过期时间，你每隔几百毫秒，就检查10万个key，那redis基本上就死了，cpu负载会很高的，消耗在你的检查过期key上了。注意，这里可不是每隔100ms就遍历所有的设置过期时间的key，那样就是一场性能上的灾难。实际上redis是每隔100ms随机抽取一些key来检查和删除的。
持久化机制对过期key的处理
RDB对过期key的处理
过期key对RDB没有任何影响
从内存数据库持久化数据到RDB文件
持久化key之前，会检查是否过期，过期的key不进入RDB文件
从RDB文件恢复数据到内存数据库
数据载入数据库之前，会对key先进行过期检查，如果过期，不导入数据库（主库情况）
AOF对过期key的处理
过期key对AOF没有任何影响
从内存数据库持久化数据到AOF文件：
当key过期后，还没有被删除，此时进行执行持久化操作（该key是不会进入aof文件的，因为没有发生修改命令）
当key过期后，在发生删除操作时，程序会向aof文件追加一条del命令（在将来的以aof文件恢复数据的时候该过期的键就会被删掉）
AOF重写
重写时，会先判断key是否过期，已过期的key不会重写到aof文件
内存淘汰机制
内存淘汰引入
想一想，redis服务器默认过期内置策略是：惰性删除+定期删除。
所谓定期删除，指的是redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。假设redis里放了10万个key，都设置了过期时间，你每隔几百毫秒，就检查10万个key，那redis基本上就死了，cpu负载会很高的，消耗在你的检查过期key上了。注意，这里可不是每隔100ms就遍历所有的设置过期时间的key，那样就是一场性能上的灾难。实际上redis是每隔100ms随机抽取一些key来检查和删除的。
但是问题是，定期删除可能会导致很多过期key到了时间并没有被删除掉，那咋整呢？所以就是惰性删除了。这就是说，在你获取某个key的时候，redis会检查一下 ，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会给你返回任何东西。
并不是key到时间就被删除掉，而是你查询这个key的时候，redis再懒惰的检查一下。
通过上述两种手段结合起来，保证过期的key一定会被干掉。
很简单，就是说，你的过期key，靠定期删除没有被删除掉，还停留在内存里，占用着你的内存呢，除非你的系统去查一下那个key，才会被redis给删除掉。
但是实际上这还是有问题的，如果定期删除漏掉了很多过期key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？
如果大量过期key堆积在内存里，导致redis内存块耗尽了，咋整？
答案是：走内存淘汰机制。
内存淘汰机制
如果redis的内存占用过多的时候，此时会进行内存淘汰，有如下一些策略：
redis 10个key，现在已经满了，redis需要删除掉5个key
1个key，最近1分钟被查询了100次
1个key，最近10分钟被查询了50次
1个key，最近1个小时倍查询了1次
1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了
2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的key给干掉啊
4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key（这个一般不太合适）
5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key
6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除