redis过期key的管理

why：

　　redis中的数据可以有一个过期时间，比如验证码、token等。当数据过期限后，是应该要被删除。

　　redis一般采用：惰性删除 + 定期删除 的策略

 

what：

　　定时删除：

　　　　当放入数据后，设置一个定时器，当定时器读秒完毕后，将对应的数据从dict中删除（用时间换空间）。

　　　　优点： 内存友好，数据一旦过期就会被删除
　　　　缺点： CPU不友好，定时器耗费CPU资源，并且频繁的执行清理操作也会耗费CPU资源。

 

　　惰性删除：

　　　　当数据过期的时候，不做任何操作。当访问数据的时候，查看数据是否过期，如果过期返回null，并且将数据从内存中清除。如果没过期，就直接返回数据（空间换时间）。　

　　　　优点： CPU友好，数据等到过期并且被访问的时候，才会删除。
　　　　缺点： 内存不友好，会占用大量内存。

 

　　定期删除：

　　　　定期删除是定时删除和惰性删除的折中方案，即：每隔一段时间对redisServer中的所有redisDb的expires进行随机抽取检查。

　　　　redis中有一个server.hz定义了每秒钟执行定期删除的次数，每次执行的时间为250ms/server.hz。redis中会维护一个current_db变量来标志当前检查的数据库。current_db++，当超过数据库的数量的时候，会重新从0开始。　　

　　　　定期检查就是执行一个循环，循环中的每轮操作会从current_db对应的数据库中随机依次取出w个key，查看其是否过期。如果过期就将其删除， 并且记录删除的key的个数。如果过期的key个数大于25%，就会继续检查当前数据库，当过期的key小于25%，会继续检查下一个数据库。

　　　　当执行时间超过规定的最大执行时间的时候，会退出检查。一次检查中可以检查多个数据库，但是最多检查数量是redisServer中的数据库个数，也就是最多只能从当前位置检查一圈。

　　　　优点： 通过控制定时时间来动态的调整CPU和内存之间的状态，十分灵活。
　　　　缺点： 定期删除的定时时间十分重要，如果时间过短，就会对CPU造成很大压力。如果时间过长，就会造成过期数据挤压内存。

 

　　　　注意：过期key是随机从全部的含有过期时间的key中进行选择。使用的算法如下，这里存在的不足是“当过期key数量较少时，哈希桶槽位上大部分的元素为空，随机数生成后所得到的哈希桶槽位经常miss，需要再次进行随机，会消耗过多的时间片在生成随机数上，而不是清理过期key”。此外，如果redis的写入量比较大，且key过期时间比较短，也会超过redis的处理能力，依然会造成数据的堆积，如果容量继续上涨超过，就会进行内存淘汰（使用allkeys-lru淘汰策略，会优先删除lru较小的key，由于惰性删除的原因，已过期的key的lru会通常情况下比较小，会被优先逐出）。

　　　　　　人为方案：人为触发过期key淘汰的方法，就是通过scan命令来进行全库的扫描，通过控制scan命令的游标和count数量，可以预期的控制淘汰的激烈程度，不会对主线程造成阻塞。

　　　　　　redis6优化，首先将原来的随机抽样检查过期key变成了按照哈希桶顺序遍历检查过期key。通过在redisDb结构体中增加long expires_cursor字段，用来记录上一次遍历到的游标位置，每次遍历都会取到这个游标位置对应的索引，然后继续下去，使得cpu的时间片更多的用来进行key过期的判断和删除上。

　　

how：

　　总体方案：

　　　　redisDb中有两个dict对象，dict内部实现的是哈希表的结构。两个dict对象的名字一个叫dict，一个叫expires。dict用于存放实际数据、expires用于存放有过期时间数据。

　　　　当往redisDb中的dict中加入key-value数据的的时候，并且为数据设置了过期时间的时候，会将对应的key和过期时间存放到expires中，便于后期查找过期时间。