java redis阻塞访问_redis系列之淘汰删除，主动被动双管齐下式保障-CSDN博客

本文链接：https://blog.csdn.net/weixin_31664931/article/details/113537522

本文探讨了Redis如何通过主动和被动删除机制实现key的过期管理，比较了两种策略的优缺点，并介绍了内存淘汰策略，包括`volatile-lru`、`allkeys-lru`等选项。重点讲解了Redis的maxmemory配置及其在内存满时的清理机制。

摘要由CSDN通过智能技术生成

redis可以针对key设置过期时间，如果到了过期时间，redis是如何让其失效呢？redis提供了两种让key过期的方法，一种是主动删除，另一种被动删除。

被动删除

当读/写一个已经过期的key时，会触发被动删除策略，直接删除掉这个过期key。

被动删除只有key被操作时(如GET)，REDIS才会被动检查该key是否过期，如果过期则删除之并且返回NIL。如果系统中存在大量的不经常访问的过期数据，会造成内存的浪费。

优点：被动删除对于cpu友好，不需要消耗cpu资源。

缺点：对于内存不友好，失效的key仍然占用内存。

主动删除

由于被动删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰一批已过期的key。采用的是贪心算法。key的定期删除会在Redis的周期性执行任务默认每100ms(可以通过hz参数自定义)执行一次，针对每个db，每次循环随机选择20个key判断是否过期，如果一轮所选的key少于25%过期，则终止此次任务。如果超过25%则继续新的一轮选择，如果此次任务超过一定的时间也会被终止，避免长时间消耗cpu，造成性能损耗。

优点：主动删除对于内存友好，能够定期删除一些失效的key，释放内存空间

缺点：对于cpu不友好，需要消耗cpu资源

注意：hz调大将会提高Redis主动淘汰的频率，如果你的Redis存储中包含很多冷数据占用内存过大的话，可以考虑将这个值调大，但Redis作者建议这个值不要超过100。我们实际线上将这个值调大到100，观察到CPU会增加2%左右，但对冷数据的内存释放速度确实有明显的提高。

如果redis配置了主从，这两种删除，只会在master中执行，然后通过del key的方式同步到slave。

淘汰策略

如果失效的key没有被访问，也未被主动删除随机选中，那这个key就永远不会失效吗？

redis中有一个maxmemory配置，即redis最大能使用的内存，当redis的使用内存达到这个值，会根据配置的淘汰策略，对redis的key进行淘汰。

volatile-lru：只对设置了过期时间的key进行LRU(默认值)
allkeys-lru ：删除lru算法的key
volatile-random：随机删除即将过期key
allkeys-random：随机删除
volatile-ttl ：删除即将过期的
noeviction ：永不过期，返回错误

注意：当mem_used内存已经超过maxmemory的设定，对于所有的读写请求，都会触发redis.c/freeMemoryIfNeeded(void)函数以清理超出的内存。注意这个清理过程是阻塞的，直到清理出足够的内存空间。所以如果在达到maxmemory并且调用方还在不断写入的情况下，可能会反复触发主动清理策略，导致请求会有一定的延迟。

主动和被动都是为了提供更多的保障。很多场景都可以使用，如数据之间的同步，数据库mysql和redis的数据同步，主动的方式通过消息队列，通知redis更新，被动的方式使用定时任务，定期全量同步，从而达到数据的一致性。因为通过消息队列，可能会存在消息的阻塞、消息中间件服务不work，消息丢失等异常情况。携程开源框架配置中心apollo，也采用了主动和被动通知的两种方式，主动的方式是config-server和客户端保持长连接，一旦配置发生修改通知客户端，被动方式是客户端定时去向config-server拉取最新的配置。中心思想就是保证服务的高可用，降低出错概率。

java设计模式系列文章：

java设计模式之代理模式，看我72变

java设计模式之模板模式，站在巨人的肩膀上成功

java设计模式之迭代器模式，顾客永远的上帝

java设计模式之适配器模式，大丈夫能屈能伸

java设计模式之构建模式，私人订制更具特色

java设计模式之组合模式，男女搭配干活不累

java设计模式之状态模式，策略模式孪生兄弟

java设计模式之责任链模式，一个也不能少，每个人都是主角

java设计模式之桥接模式，策略模式旗舰版，世界没有免费的午餐

java设计模式之原型模式，如有雷同，纯属巧合

设计模式之命令模式，各司其职提高效率