所有 redis 数据结构均支持设置过期时间，当时间到期时，redis 自动删除该数据结构。你可以想象 redis 内部有一个死神，时刻盯着所有设置了过期时间的 key，寿命一到就会立即收割。
你可以考虑从死神的视角出发，是否因为太多的 key 同时过期而导致无法处理。同时因为 Redis 是单线程的，收割的时间也会占用线程的处理时间，如果收割的太过于繁忙，会不会导致线上读写指令出现卡顿。
过期的 key 集合
redis 会将每个设置了过期时间的 key 放入到一个独立的字典中，以后会定时遍历这个字典来删除到期的 key。除了定时遍历之外，它还会使用惰性策略来删除过期的 key，所谓惰性策略就是在客户端访问这个 key 的时候，redis 对 key 的过期时间进行检查，如果过期了就立即删除。定时删除是集中处理，惰性删除是零散处理。
定时扫描策略
Redis 默认会每秒进行十次过期扫描，过期扫描不会遍历过期字典中所有的 key，而是采用了一种简单的贪心策略。
从过期字典中随机 20 个 key；
删除这 20 个 key 中已经过期的 key；
如果过期的 key 比率超过 1/4，那就重复步骤 1；
同时，为了保证过期扫描不会出现循环过度，导致线程卡死现象，算法还增加了扫描时间的上限，默认不会超过 25ms。
设想一个大型的 Redis 实例中所有的 key 在同一时间过期了，会出现怎样的结果？
毫无疑问，Redis 会持续扫描过期字典 (循环多次)，直到过期字典中过期的 key 变得稀疏，才会停止 (循环次数明显下降)。这就会导致线上读写请求出现明显的卡顿现象。另一种导致卡顿的原因是内存管理器需要频繁回收内存页，这也会带来一定的 CPU 消耗。
当客户端请求到来时，服务器如果正好进入过期扫描状态，客户端的请求将会等待至少 25ms 后才会进行处理，如果客户端将超时时间设置的比较短;
如果超时时间设置为10ms，会导致大量连接因为超时而关闭，从而使业务端出现大量异常。而且这时你还无法从 Redis 的 slowlog 中看到慢查询记录，因为慢查询指的是逻辑处理过程慢，不包含等待时间。
