redis的热key、大key

忘是亡心i 2023-09-23 18:07 135阅读 0赞

**目录**

1.概述

2.查找方法

2.1.知道具体哪个key有问题

2.2.不知道具体哪个key有问题

3.处理方法

3.1.大key的处理方法

3.2.热key的处理方法

--------------------

## 1.概述 ##

**大key：**

含有较大数据或含有大量成员的Key称之为大Key，常见的大key如：

*  String类型的Key值大于10kb
 *  list、set、zset、hash的成员个数超过5000
 *  list、set、zset、hash的成员数量虽然只有1000个但这些成员的value总大小为100MB（成员体积过大）

注意：以上值只是参考，根据实际情况确定。

**热key：**

某个Key接收到的访问次数、显著高于其它Key时，称之为热Key。

**大key带来的问题：**

1.  对Redis的请求变慢。
2.  Redis内存不断变大引发OOM，或达到maxmemory值引发写阻塞或重要Key被逐出。
3.  Redis Cluster中的某个node内存远超其余node。
4.  由于对大key的请求很慢，容易造成请求的阻塞，在分布式架构下容易造成服务雪崩。
5.  删除一个大Key很耗时，容易造成主结点阻塞，从而主从切换。

**热key带来的问题：**

1.  大量请求直接打过来，服务器可能会扛不住，造成缓存击穿从而直接打挂后端存储（数据库），影响其他使用后端存储的业务。
2.  可能使得redis的集群失去意义，Redis Cluster中各node流量不均衡造成Redis Cluster的分布式优势无法被利用，一个分片负载很高而其它分片十分空闲。

**大key、热key的产生原因：**

1.  存放不合理，存储了不适合存放在内存中的数据，如用key存放音频视频这一类大体积二进制文件（大key）。
2.  设计不合理，造成个别key中成员过多。（大key）。
3.  未定期清理数据，没有设置过期时间，造成了如hash类型中key中的成员不断增加。
4.  流量陡增，如出现某款爆款商品等（热key）。
5.  bug，代码的业务逻辑上对key的成员只增不减也未设置过期时间。

## 2.查找方法 ##

### 2.1.知道具体哪个key有问题 ###

**利用调试指令进行分析查找大key：**

debug key名，对Key进行分析并返回分析结果，其中serializedlength的值为该Key的序列化长度，序列化长度可以作为key大小的判断参考，但不一定准确。而且debug命令属于调试命令，在其运行时，进入Redis的其余请求将会被阻塞直到其执行完毕。线上环境进行分析不推荐该命令。

**利用操作指令进行分析查找大key：**

redis的各个数据结构的操作API自带返回其成员长度的命令。利用这些命令进行分析风险更小。

![292bedcf70d14228972a9cd689829f05.png][]

### 2.2.不知道具体哪个key有问题 ###

前面的指令都是对具体的key进行分析，在不知道哪个key会有问题的时候，可以使用参数进行分析。

redis-cli的bigkeys参数用于查找大key。bigkeys仅能分别输出最大Key，如果想进行范围查询，比如找出全部成员数量超过10的hash，bigkeys是办不到的。

redis-cli的hotkeys参数用来分析热key，该参数能够返回所有Key的被访问次数，试用hotkeys的前提条件是将redis-server的maxmemory-policy参数设置为LFU。

## 3.处理方法 ##