Redis过期性能其实没那么难提升，你也能搞定那些瓶颈问题

很多人一提到Redis的性能瓶颈,首先想到的是CPU、内存或者网络带宽，这些确实很重要，但有一个经常被忽视却又频繁引发问题的点，就是键的过期处理机制，你可能遇到过这种情况：Redis明明没到内存上限，但偶尔会出现响应变慢，甚至出现短暂的卡顿，这很可能就是过期键在“搞鬼”。（来源：Redis官方文档关于过期机制的说明）

Redis里设置了过期时间的键,并不是说一到点就立刻被删除的，如果真是那样，当有大量键同时过期时，Redis光忙着删除这些键就得花很长时间，肯定会阻塞住其他操作，导致服务不可用，Redis采用了一种更聪明但也更复杂的策略，主要是两种方法结合：惰性删除和定期删除。（来源：Redis作者Salvatore Sanfilippo在多篇博客和讨论中阐述的设计思想）

惰性删除,顾名思义，就是很“懒”，它不会主动去检查哪个键过期了，而是当你去访问一个键的时候，Redis才会顺便检查一下这个键是否已经过期，如果过期了，就立刻删除它，然后返回空，就像这个键从来不存在一样，这种方式的好处是省CPU，只在必要的时候才干活，但坏处也很明显，如果一个过期的键永远没人来访问，那它就会一直占着内存，成了“僵尸键”，只有等到以后被访问时或者通过其他机制才会被清理掉。（来源：《Redis设计与实现》一书中对过期策略的详解）

光靠“懒”肯定不行，内存会被这些僵尸键撑爆，所以Redis还有个“定期删除”的机制来兜底，它会每隔一段时间，主动地随机抽查一批设置了过期时间的键，把其中已经过期的删除掉，这个过程是分批次、分数据库进行的，不会一次性干到底，以免长时间阻塞系统，你可以把它想象成一个保洁阿姨，她不会每天24小时不停地打扫整个大楼，而是每隔一小时，随机抽查几个房间，把里面的垃圾清走，这样既保证了整体环境的清洁，又不会影响大楼里人员的正常工作。（来源：Redis源码中关于activeExpireCycle函数的注释说明）

问题来了,既然策略听起来挺完善，为什么还会出现因为过期导致的性能瓶颈呢？瓶颈往往就出现在那个“定期删除”的环节上，当你的Redis实例中，存在大量设置了相同过期时间的键时（所有缓存都设置为1小时后过期），就容易引发问题，想象一下，在某个时间点，有几十万甚至上百万个键同时过期，到了定期删除的周期，Redis需要检查并清理的键数量会非常庞大。（来源：多位Redis贡献者在GitHub Issues中讨论大量键同时过期带来的延迟问题）

虽然定期删除是分步进行的,但如果过期的键实在太多，每一步需要处理的工作量就会很大，Redis为了保证自身不卡死，会限制每次定期删除的执行时长，这样一来，单次清理可能就清理不完所有过期键，剩下的过期键会留到下一个周期，这会导致两个后果：第一，内存可能迟迟无法释放，因为“僵尸键”清理得慢；第二，定期删除这个动作本身会变得更频繁、更耗时，因为它总是有“历史欠账”要还，这就会反映为Redis的周期性延迟增高，你在监控上可能会看到规律的性能毛刺。（来源：云服务商如AWS、阿里云等在其优化建议文档中提到的典型案例）

那作为使用者,我们怎么能避免掉进这个坑里呢？方法其实不复杂，核心思路就四个字：打散过期。（来源：Redis最佳实践相关的多篇技术博客总结）

1. 给过期时间加个随机数。 这是最简单也最有效的一招，你的缓存原本想设置1小时过期，现在可以改成“1小时 + 一个0到300秒之间的随机数”，这样，大量键同时刻过期的概率就大大降低了，过期时间被均匀地打散在了一个时间窗口内，定期删除任务每次需要处理的键数量就会保持在一个平稳的水平，不会出现剧烈的波峰，这就像让一大群人不要同时挤过一个独木桥，而是让他们稍微错开时间通过，桥的通行压力就小多了。

2. 谨慎使用非常短的过期时间。 如果你把过期时间设置得很短，比如几秒钟，那么键的生命周期就会非常快，过期和创建的频率会很高，这会给惰性删除和定期删除都带来不小的压力，除非业务场景必需，否则尽量避免使用秒级的过期时间。

3. 监控慢查询和延迟。 使用Redis的SLOWLOG命令或者监控工具，密切关注是否有因为过期键清理导致的慢查询，监控服务器的内存使用情况和延迟指标，如果发现规律的性能毛刺，就可以往键过期这个方向去排查。

4. 考虑使用不同数据库或实例做隔离。 如果有些业务就是会产生大量同时过期的键，并且难以通过打散时间来解决，可以考虑将这部分缓存放到一个独立的Redis数据库甚至独立的Redis实例中，这样，它的定期删除操作就不会影响到其他关键业务的性能。

Redis的过期性能瓶颈并不是一个无法解决的黑盒问题,只要你理解了它背后“惰性删除+定期删除”的工作原理，特别是认识到“大量键同时过期”是罪魁祸首，就能有针对性地进行优化，核心技巧就是通过给过期时间添加随机值，把集中式的清理压力转化为分布式的、平滑的压力，这样一来，你就能轻松搞定这个隐藏的性能杀手，让Redis跑得更稳更快。