本文已收录于专栏
《Redis精通系列》
上千人点赞收藏，全套Redis学习资料，大厂必备技能！
目录
1、简介
2、过期策略
2.1 主动删除
2.2 被动删除
3、如何正确的设置key的过期时间
4、从节点存在的问题
1、简介
Redis的数据结构均可以通过EXPIRE key seconds 的方式设置key的过期时间（TTL）。我们也习惯的认为Redis的key过期时间到了，就会自动删除，显然这种想法并不正确。Redis的设计考虑到性能/内存等综合因素，设计了一套过期策略。
2、过期策略
Redis key过期删除有两种方式
主动删除
被动删除
2.1 主动删除
当key被访问的时候，先校验key是否过期，如果过期了则主动删除。
2.2 被动删除
Redis服务器定时随机的测试key的过期时间，如果过期了则被动删除。被动删除的存在必不可少，因为存在一些过期且永久不在访问的key，如果都依赖主动删除，那么它们将会永久占用内存。
Redis为了保证提供高性能服务，被动删除过期的key，采用了贪心策略/概率算法，默认每隔10秒扫描一次，具体策略如下：
从过期字典（设置了过期时间的key的集合）中随机选择20个key，检查其是否过期
删除其中已经过期的key
如果删除的过期key数量大于25%，则重复步骤1
3、如何正确的设置key的过期时间
开发在设计Redis缓存架构时，一定要注意要尽可能的避免（禁止）将大量的key设置为同一过期时间，因为结合2.2被动删除可知，Redis被动删除过期key时，会导致服务短暂的不可用；如果存在大量key同时过期，这会导致被动删除key的三个步骤循环多次，从而导致Redis服务出现卡顿情况，这种情况在大型流量项目是无法接收的。
因此为了避免这种情况出现，一定要将一些允许过期时间不需要非常精确的key，设置较为随机的过期时间，这样就可以将卡顿时间缩小。
4、从节点存在的问题
在主从模式下，Redis是AP架构，它具有高可用性，但是无法保证主从节点的强一致性。在Redis主从架构中，从节点不会直接发生数据的写入，过期key删除也不会在从节点直接发生，它只能被动地依靠主从同步来完成这一步骤。
当主节点中key到期时，会在AOF文件中增加DEL指令，在这个指令未同步到从节点这段时间内，从节点中的key仍然是未删除的。只有当指令同步过来之后，从节点才会删除这个key。通常情况下，这并不带来什么太大的问题，但是确实存在主从数据不一致的情况。
