Redis所有的数据结构都可以设置过期时间，时间一到就会自动删除。
思考：Redis是单线程的，删除key的时间也会占用线程的处理时间，如果删除过于频繁，会导致CPU负载过高吗，会导致线上读写指令出现卡顿吗？
下面来谈谈Redis的两种删除策略。
两种删除策略
定时删除（集中处理）
Redis会将每个设置了过期时间的key放入到一个独立的字典中，定时遍历这个字典来删除到期的key。
Redis默认每秒进行十次过期扫描，过期扫描不会遍历过期字典中的所有key，而是采用了一种简单的贪心策略。
- 从过期字典中随机20个key；
- 删除这20个key中已经过期的key；
- 如果过期Key的比率超过四分之一，重复步骤1。
同时为了保证不会出现循环过度导致线程卡死，算法增加了扫描时间上线（默认25ms）。
惰性删除（零散处理）
Redis在客户端访问这个key的时候，会对key的过期时间进行检查，如果过期了就立即删除。
Redis中大量key同一时间过期问题
Redis实例中存在大量同一时间过期的key过期时，Redis会持续扫描过期（循环多次），直到过期字段中过期的key变得稀疏，才会停止（循环次数明显下降）。这就会导致线上读写请求出现明显的卡顿现象。导致这种卡顿的另外一种原因是内存管理器需要频繁的回收内存页，产生CPU消耗。
扫描上线25ms看起来不会导致卡顿，假设101个客户端同事将请求发送过来，前100个请求的执行时间都是25ms，那么第101个指令需要等待2500ms才能执行，这就是客户端卡顿时间，由于服务器不间断的小卡顿积少成多。
所以开发时需要注意过期时间，如果有大批量key过期，要给过期时间设置一个随机范围，而不能全部在同一时间过期。
实践中如电商降价活动是一期一期举办的，下期举办时，前面几期的数据可以过期了，所以一般都会设置一个过期时间，减少不必要的内存占用，这个时候就需要将这些同时设置过期时间的商品使用固定时间+随机时间，让这些key不会同时过期。
从库的过期策略
从库不会进行定期扫描，对过期的处理是被动的。主库在key到期时，会在AOF文件里面增加一条del命令，同步到所有的从库，从库通过执行这条del指令来删除过期的key。
因为指令同步是异步进行的，所以主库过期的key的del指令没有及时同步到从库的话，会出现主从数据不一致的情况。例如集群环境下分布式锁的算法漏洞就是因为这个同步延时产生的。
