查看原文
其他

执行个 DEL 竟然也会阻塞 Redis?深挖一下果然不简单

张张 架构精进之路
2024-08-31

hello,大家好,我是张张,「架构精进之路」公号作者。


前两天有同事在执行 DEL 进行Redis数据删除的时候,阻塞Redis造成服务报警。

相信很多人对此不能理解:

  • DEL 操作不就是从Redis DB 字典中删除过期 key 么?

  • 它的时间复杂度不就是 O(1) 么?

  • 为什么会对Redis造成阻塞呢?
这篇文章,我就来和你盘点一下,使用 Redis DEL 会踩到「坑」,以及深挖下其中的原理。

1. DEL 命令的时间复杂度

删除一个 key,你肯定会用 DEL 命令,它的时间复杂度是多少呢?
是 O(1) 么?
其实不一定。
如果你有认真阅读 Redis 的官方文档,就会发现:删除一个 key 的耗时,与这个 key 的类型有关。
Redis 官方文档在介绍 DEL 命令时,是这样描述的:
  • key 是 String 类型,DEL 时间复杂度是 O(1)
  • key 是 List/Hash/Set/ZSet 类型,DEL 时间复杂度是 O(M),M 为元素数量
也就是说,如果你要删除的是一个非 String 类型的 key,这个 key 的元素越多,那么在执行 DEL 时耗时就越久!
为什么会是这样呢?
原因就在于:删除这种 key 时,Redis 需要依次释放每个元素的内存,元素越多,这个过程就会越耗时。
而这么长的操作耗时,势必会阻塞整个 Redis 实例,影响 Redis 的性能。
接下来,我们再来分析下,删除一个 String 类型的 key 会不会有这种问题?
前面不是提到过,Redis 官方文档的描述,删除 String 类型的 key,时间复杂度是 O(1) 么?这不会导致 Redis 阻塞吧?
其实,这也 不 一 定

2. Redis 的删除策略

Redis 主要提供两种删除策略:
  • 请求时删除:执行命令操作时,先检查下 key 是否已经过期,若已过期则删除,反之,继续操作。
  • 定期清理:请求时删除的补充,按一定的请求频率清理已过期的 key。
其中,针对定期清理 redis 提供了两种触发机制:
  • 一种是低频次,频率由周期性 server.hz 决定。
  • 另一种是高频次,频率与主事件循环有关,由 beforeSleep 方法触发。
其实不管哪种方式触发,都需要考虑这个问题:不能对服务造成长时间的阻塞
现实中总会有各种各样难以解决的问题:
  • 假如我们一次性过期很多 key,要一次性清理该怎么办?
  • 假如有个大 key,要花很长时间才能删除掉,又该怎么办?
你考虑一下,如果这个 key 占用的内存非常大呢?
例如,这个 key 存储了 800MB 的数据(很明显,它是一个 bigkey),那在执行 DEL 时,耗时依旧会变长!
这是因为,Redis 释放这么大的内存给操作系统,也是需要时间的,所以操作耗时也会变长。
所以,对于 String 类型来说,你最好也不要存储过大的数据,否则在删除它时,也会有性能问题。

3. 如何稳妥的进行 Redis 删除

当我们在删除 List/Hash/Set/ZSet 类型的 key 时,一定要格外注意,不能无脑执行 DEL,而是应该用以下方式删除:
  1. 查询元素数量:执行 LLEN/HLEN/SCARD/ZCARD 命令
  2. 判断元素数量:如果元素数量较少,可直接执行 DEL 删除,否则分批删除
  3. 分批删除:执行 LRANGE/HSCAN/SSCAN/ZSCAN + LPOP/RPOP/HDEL/SREM/ZREM 删除
主要采用以下两种原则来应对:
  • 少量、高频次 进行过期数据清理
  • 大 key 采用异步惰性删除策略,避免主线程阻塞
从触发删除时机来看,redis 主要有两种触发场景:
  • 请求时触发:对所有请求命令执行之前都检查下 key 是否过期。
  • 定期触发:定期的检查下是否有 key 过期,有的话就尝试删除。
关于请求时触发,本质上这是一种 惰性 的思想,你主动发起请求了,我就顺便帮你检查下当前状态,如果没有请求,那么我就不做任何处理。
站在系统的角度,它需要客户端触发,然后系统被动的接受指令。
此时,你可能会想:Redis 4.0 不是推出了 lazy-free 机制么
打开这个机制,释放内存的操作会放到后台线程中执行,那是不是就不会阻塞主线程了?
那真的会是这样吗?

4. 什么是 lazy-free?

在应用之前,我们首先要搞清楚,什么是lazy-free?
lazy-free是4.0新增的功能,但是默认是关闭的,需要手动开启。这里的 lazy-free,将慢操作异步化,这也是在事件处理上向多线程迈进了一步。
惰性删除的意思是:将释放内存的操作交给后台线程异步的进行处理,也就意味着一个 key 真正意义上的删除,具有一定的延迟。
惰性,就体现在删除操作并没有真正执行,而是交给后台线程异步处理,可能比实际响应结果要晚一些才真正完成。
从 DB 中删除过期 key 时,只是从 DB 字典中将关系删除,内存没有真正释放,而是交给后台异步线程去删除。
主线程将待删除的 key 扔到 lazy_free 队列,并唤醒对应的后台线程,此时 bio_lazy_free 后台线程就从队列中取出对应的 key 进行内存清理。这也是一个典型的 生产者 - 消费者 模型。

5. DEL bigkey 会阻塞

手动开启lazy-free时,有4个选项可以控制:
  • lazyfree-lazy-expire:key在过期删除时尝试异步释放内存
  • lazyfree-lazy-eviction:内存达到maxmemory并设置了淘汰策略时尝试异步释放内存
  • lazyfree-lazy-server-del:执行RENAME/MOVE等命令或需要覆盖一个key时,删除旧key尝试异步释放内存
  • replica-lazy-flush:主从全量同步,从库清空数据库时异步释放内存
除了replica-lazy-flush之外,其他情况都只是可能去异步释放key的内存,并不是每次必定异步释放内存的。
开启lazy-free后,Redis在释放一个key的内存时,首先会评估代价,如果释放内存的代价很小,那么就直接在主线程中操作了,没必要放到异步线程中执行(不同线程传递数据也会有性能消耗)。
那什么情况才会真正异步释放内存?
这和key的类型、编码方式、元素数量都有关系:
  • 当Hash/Set底层采用哈希表存储(非ziplist/int编码存储)时,并且元素数量超过64个
  • 当ZSet底层采用跳表存储(非ziplist编码存储)时,并且元素数量超过64个
  • 当List链表节点数量超过64个(注意,不是元素数量,而是链表节点的数量,List的实现是在每个节点包含了若干个元素的数据,这些元素采用ziplist存储)
  • 再加一个条件就是refcount=1 就是没有人在引用这个key的时候
只有以上这些情况,在删除key释放内存时,才会真正放到异步线程中执行,其他情况一律还是在主线程操作。
也就是说String(不管内存占用多大)、List(少量元素)、Set(int编码存储)、Hash/ZSet(ziplist编码存储)这些情况下的key在释放内存时,依旧在主线程中操作。
由此可见,即使开启了lazy-free,String类型的bigkey,在删除一个 String 类型的 bigkey 时,它仍旧是在主线程中处理,而不是放到后台线程中执行,依旧有阻塞 Redis 的风险!

6. 总结

其实,接触任何一个新领域,都会经历陌生、熟悉、踩坑、吸收经验、游刃有余这几个阶段。
踩坑不可怕,根据问题再深挖一下,一定能收获到你期望的答案。
本文通过对Redis DEL 命令的一系列分析,总结来看,Redis 有自己的一套代价评估方法,认为可以清理代价较大,才会交给后台线程惰性处理;反之,顺手就给清理了。
最后忠告各位开发同学,即便Redis提供了lazy-free,我建议还是尽量不要在Redis中存储bigkey

我是 张张,一个对于技术有思考的资深后端程序员,在每一篇文章中,我不仅会告诉你一个技术点是什么,还会尝试把这些问题探究的思考过程提炼成通用的方法论,让你可以应用在其它领域中,做到举一反三。

如果文章对你有所帮助,还请帮忙点赞、在看、转发一下,你的支持会激励我输出更高质量的文章,非常感谢!


关注公众号,免费领学习资料


如果您觉得还不错,欢迎关注和转发~     

继续滑动看下一个
架构精进之路
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存