redis 过时策略

Redis 全部的数据结构均可以设置过时时间，时间一到，就会自动删除。你能够想象 Redis 内部有一个死神，时刻盯着全部设置了过时时间的 key，寿命一到就会当即收割。

你还能够进一步站在死神的角度思考，会不会由于同一时间太多的 key 过时，以致于忙不过来。同时由于 Redis 是单线程的，收割的时间也会占用线程的处理时间，若是收割的太过于繁忙，会不会致使线上读写指令出现卡顿。

这些问题 Antirez 早就想到了，全部在过时这件事上，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 中看到慢查询记录，由于慢查询指的是逻辑处理过程慢，不包含等待时间。

因此业务开发人员必定要注意过时时间，若是有大批量的 key 过时，要给过时时间设置一个随机范围，而不宜所有在同一时间过时，分散过时处理的...