Redis调优-BigKey问题

最新推荐文章于 2024-11-11 20:37:25 发布

weixin_44145526

最新推荐文章于 2024-11-11 20:37:25 发布

阅读量38

点赞数

分类专栏： Redis 文章标签： redis 数据库缓存

原文链接：https://blog.csdn.net/weixin_39682329/article/details/136986477?spm=1001.2014.3001.5501

版权

Redis 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

什么是大Key,多大是大Key?

Redis中的大key，实际上指的是key所关联的value值特别大，比如字符串过大或者是某种数据结构（如hash,list ,set,zset)中存储了过多的元素。
详情可参照《阿里Redis开发规范》，一般来将，String类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000

为什么会产生BigKey?

大key的产生一般与业务方设计有关，对value的动态增长问题预估不足。造成大key问题的原因有：

数据结构设计不合理
在不合适的场景下，使用Redis,易造成Key的value过大，如使用String类型的Key存放大体积的二进制文件型数据。
业务规划设计不足
没有对Key中的成员进行合理的拆分将大key变成小key,从而造成个别Key中一直往value里面塞数据，没有删除机制，未定期清理无效数据，导致不断增加。
上线前期预估不足
如头条重大新闻、百度热搜，造成value值动态突增。
当某个新闻或话题突然变得非常热门时，大量用户会在短时间内访问和互动。这些用户行为数据（如点击量、点赞数、评论等）可能会累积在某个Redis key对应的value中，使得这个value变得非常大。例如，一个热门话题的讨论列表，包含成千上万条评论和回复，这些数据可能全部存储在一个key的value中。
汇总统计类，随着时间推移value逐渐增加。
假设实时统计一个网站每个页面的访问次数以及每个页面的访问用户列表

产生大key会有什么问题？

内存不足（因为redis基于内存）
删除超时
当一个key的value非常大（例如一个包含大量元素的列表、集合或哈希表），删除这个key需要遍历和释放内存中的所有元素。这个过程会占用大量时间，尤其是当key包含数百万个元素时。
Redis是单线程模型，这意味着所有操作都是在单个线程上顺序执行的。如果一个操作（如删除大key）需要很长时间，这个操作会阻塞其他操作的执行，导致响应时间变长。
网络阻塞
对大key的操作（如读取、写入、删除）需要在Redis服务器和客户端之间传输大量数据。如果key的value非常大，比如包含数百万个元素的列表或集合，那么一次操作需要传输的数据量也非常大，导致网络带宽被大量占用。
集群节点容易倾斜甚至宕机
负载不均：大key所在的节点负载过重，导致集群负载不均衡，影响整体性能。
热点问题：大key会成为热点，集中大量访问请求到单个节点，增加该节点的负载。

如何判定redis变慢了？

1.Redis基准性能测试
2.使用Redis慢日志

如何发现BigKey?

使用redis-cli --bigkeys给出每种数据结构最大的bigkey,同时给出每种数据类型的键值个数和平均大小。

如何处理大Key?

按照不同的数据类型，给出不同的命令：

String类型: DEL/UNLINK

删除Redis中String类型的大Key，你可以使用DEL命令：
如果你使用的是Redis的集群模式，可以使用redis-cli的-c选项来启用集群模式，并执行删除命令。
由于DEL命令会对Redis服务器造成阻塞，可以考虑使用UNLINK命令。Redis 4.0及以上版本中可用，它会异步地删除Key，避免阻塞。
注意: 即使使用UNLINK命令，删除非常大的Key仍然可能会对Redis服务器造成一些影响，因为它仍然需要释放内存。因此，在生产环境中执行此类操作时，请务必谨慎，并考虑在低峰时段进行，同时监控Redis的性能指标。

Hash类型: HSCAN + HDEL
List类型: LTRIM渐进式删除
Set类型:使用 sscan每次获取部分元素，再使用 srem命令删除每个元素
Zset类型：使用 zscan每次获取部分元素，再使用 ZREM命令删除每个元素