用Redis处理过期数据其实没那么难，自动清理功能挺方便的

（根据微信公众号“运维漫谈”发布的文章《别怕，Redis过期策略帮你轻松搞定数据清理》整理）

用Redis处理过期数据，很多人一开始会觉得这是个挺麻烦的事儿，怕数据堆在那里把内存撑爆了，但其实啊，Redis自己就带了很聪明的自动清理功能，用起来比我们想象中要方便得多，它主要靠两招儿来搞定过期数据：一个叫“定期删除”，另一个叫“惰性删除”，这两招儿配合着用,基本上就不用我们太操心了。

先说说这个“惰性删除”，这个名字听起来可能有点技术感，但道理特别简单，你可以把它想象成一个特别较真的图书馆管理员，当有读者（也就是客户端）来借某一本书（也就是某个Key）时，这个管理员不会提前把过期的书都清理掉，他没那么勤快，他只会当你来借这本书的时候，才顺手看一下这本书的借阅期限（过期时间）到了没有，如果到了，他就会对你说：“对不起，这本书已经过期了，不能借了。”然后他不仅不把书给你，还会顺手把这本书从书架上拿走，扔进回收箱，这个过程就是惰性删除，它的好处是只在真正需要访问这个Key的时候才进行检查和删除，节省了CPU资源，但缺点也很明显，如果一本书永远没人来借，哪怕它早就过期了，也会一直占着书架的位置,这个管理员是不会主动去清理它的。

（参考来源：Redis官方文档中关于“惰性删除”的说明部分）

那些永远没人访问的过期Key怎么办呢？总不能让他们一直霸占着宝贵的内存空间吧？这时候，Redis的另一个机制——“定期删除”就出场了，这个机制可以想象成图书馆定期的闭馆盘点，每隔一段时间，比如每周一次，图书馆会闭馆几个小时，管理员会组织人手，分批分区域地检查书架上的所有书籍，把那些已经过期的书统统找出来扔掉，Redis也是这么干的，它会每隔100毫秒（这个时间是可以配置的）就随机地抽取一部分设置了过期时间的Key进行检查，如果发现某个Key已经过期了，就立刻删除它，这次可能抽查20个Key，下次可能抽查30个，这样分批进行，既不会因为一次性检查所有Key而导致Redis卡死（也就是性能抖动），又能保证那些“僵尸”Key最终会被清理掉。

（参考来源：博客园一位名为“码农小胖”的博主在《深入理解Redis数据过期策略》中的比喻和解释）

你看，“惰性删除”和“定期删除”就像两个默契的搭档，一个负责“即来即办”，你来访问我才处理；另一个负责“主动巡检”，时不时扫一遍角落里的垃圾，它们俩双管齐下，就能在保证性能的同时,比较有效地清理掉大部分过期数据。

万一这两种策略都失效了，比如过期Key太多，清理的速度赶不上新Key产生的速度，或者系统长时间没有访问导致大量Key积压，内存还是有可能被占满的，Redis早就想到了这一点，它还有最后一道防线，叫做“内存淘汰机制”，当内存真的要用完的时候，Redis会根据你事先设定好的规则，自动淘汰掉一些数据来腾出空间，这个规则你可以自己定，比如可以设定为“淘汰最近最少使用的数据”（LRU），就好像图书馆空间不够时，把那些很久没人看的书先处理掉；或者设定为“从已设置过期时间的数据中，随机淘汰”（volatile-random）；甚至更狠一点，“从所有数据中随机淘汰”（allkeys-random），你可以根据自己业务的重要性来选择合适的策略，这就给了我们很大的灵活性，确保在内存紧张的时候，系统还能继续运行,而不是直接崩溃。

（根据开源技术社区“掘金”上的一篇技术分享《Redis内存满了怎么办？详解8种内存淘汰策略》的内容概述）

综合来看，Redis为了帮我们处理过期数据和内存问题，真的是设计了一套挺完善的“组合拳”，从日常的随手清理（惰性删除），到定期的巡查检查（定期删除），再到紧急情况下的“断尾求生”（内存淘汰机制），层层递进，我们作为使用者，要做的就是两件事：第一，在存数据的时候，合理地给那些需要过期的数据设置一个过期时间，比如短信验证码设置5分钟过期，用户登录Token设置7天过期；第二，根据自己业务的特点，在Redis的配置文件里选一个合适的内存淘汰策略，做完这两步，剩下的事情基本上就可以放心地交给Redis自己去处理了，它就像一个配备了智能管理系统的仓库，我们只需要把货物放进去，贴上有效期标签，并设定好仓库满员时的处理规则，这个仓库自己就会井然有序地运转起来，真的没那么难,挺方便的。