By

前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、大key的危害

1、内存分布不均匀

内存使用不均匀：当slot分配均匀的时候，大key的出现会导致redis内存使用的不均。

2、容易造成网络堵塞

我理解，就是说会扫描很多内存页，每次获取bigkey产生的网络流量比较大。涉及到大key的操作，尤其是使用hgetall、lrange 0 -1、get、hmget 等操作时，网卡可能会成为瓶颈，也会到导致堵塞其它操作，qps 就有可能出现突降或者突升的情况，趋势上看起来十分不平滑，严重时会导致应用程序连不上，实例或者集群在某些时间段内不可用的状态。

假设一个bigkey为1MB，每秒访问量为1000，那么每秒产生1000MB的流量。

3、影响扩容迁移效率

我理解，就是说会扫描很多内存页，会一次性申请更大的一块内存，这也会导致卡顿

在迁移过程中，如果每个 key 的内容都很小，migrate (dump + resotre + del) 指令执行会很快，它就并不会影响 客户端的正常访问。如果 key 的内容很大，因为 migrate 指令是阻塞指令会同时导致原节点和 目标节点卡顿，影响集群的稳定型。所以在集群环境下业务逻辑要尽可能避免大 key 的产 生

4、大key删除会引起卡顿

我理解，就是说会扫描很多内存页，如果这个大 key 被删除，内存会一次性回收，卡顿现象会再一次产生。

删除指令 del 会直接释放对象的内存，大部分情况下，这个指令非常快，没有明显延迟。不过如果删除的 key 是一个非常大的对象，比如一个包含了千万元素的 hash，那么删除操作就会导致单线程卡顿。

5、Redis 官方与社区对“大 key”的定义

  • 单个 value 超过 10KB 就值得关注；
  • 超过 100KB 通常被认为是“大 key”；
  • 超过 1MB 属于严重的大 key，容易引发性能问题。
数据大小 是否算大 key 建议
< 10 KB 否 正常使用
10–100 KB 轻度关注 视使用频率和数量决定是否优化
> 100 KB 是 建议拆分或压缩
> 1 MB 严重大 key 必须优化
数据类型 “大 Key”常见阈值 风险说明
String > 10 KB（有些场景放宽到 50 KB） 单个 value 过大会导致网络传输慢、阻塞主线程（Redis 是单线程处理命令）
Hash / List / Set / ZSet 元素数量 > 5,000 ~ 10,000 个 或总大小 > 1 MB 删除、序列化、过期等操作可能造成毫秒甚至秒级延迟

二、大 key 扫描

1、--bigkeys 的作用

  • 遍历 Redis 实例中的所有 key（通过 SCAN 命令）；
  • 统计 每种数据类型（string、list、set、hash、zset）的 key 数量；
  • 在扫描过程中，动态追踪并打印当前遇到的最大 key（按大小或元素数量）的名称、类型和规模；
  • 最终在汇总（summary）部分，列出每种类型中最大的那个 key 的名称及其大小/元素数；
  • 不会返回所有 key 的列表，也不会输出“前 N 大”的完整排名。
redis-cli -h 127.0.0.1 -p 7001 –-bigkeys



[12.34%] Biggest string found so far 'cache:html:home' with 45678 bytes
[45.67%] Biggest hash found so far 'user:profile:999' with 3200 fields

-------- summary -------
Sampled 1234567 keys in 45.2 seconds
Total key count: 1234567

String: 900000
Hash:   200000
List:   100000
Set:    30000
Zset:   4567

Biggest string: 'cache:html:home' (45678 bytes)
Biggest hash: 'user:profile:999' (3200 fields)
..

2、线上风险

默认情况下，--bigkeys 会以较快频率执行 SCAN + TYPE + *LEN 等命令，可能导致：

  • OPS（每秒操作数）突增；
  • CPU 使用率升高；
  • 影响正常业务请求响应延迟。

3、安全使用

添加 -i 参数（推荐）

  • -i 0.1 表示：每处理 100 个 key 后，sleep 0.1 秒。
  • 这显著降低对 Redis 的瞬时压力，适合生产环境。
  • 扫描时间会变长，但更安全。
redis-cli -h 127.0.0.1 -p 7001 –-bigkeys -i 0.1

4、其他建议

  • 避开业务高峰期执行；
  • 如果 Redis 是集群模式（Cluster），需对每个主节点单独执行；
  • 若实例数据量极大（如数十 GB），即使加 -i 也可能耗时很久，可考虑用 redis-rdb-tools 等离线分析 RDB 文件的方式；

三、删除大key

单个耗时过大命令，导致阻塞其他命令，容易引起应用程序雪崩或Redis集群发生故障切换。所以避免在生产环境中使用耗时过大命令。

Key类型 Item数量 耗时
Hash ~100万 ~1000ms
List ~100万 ~1000ms
Set ~100万 ~1000ms
Zset ~100万 ~1000ms

1、命令直接删除

Redis 为了解决这个卡顿问题，在 4.0 版本引入了 unlink 指令，它能对删除操作进行懒处理，丢给后台线程来异步回收内存。

可以看我的另一篇文章 《朝生暮死_过期策略》

\> unlink key 
OK

2、命令缓缓删除

1）Hash

hash： 使用 hscan + hdel

2）List

scan + ltrim

3）Set

sscan + srem

4）Zset

zremrangebyrank

四、大key优化

1、String

1）该对象需要每次都整存整取

方案1： 可以尝试将对象分拆成几个key - value， 使用multiGet获取值，这样分拆的意义在于分拆单次操作的压力，将操作压力平摊到多个redis实例中，降低对单个redis的IO影响；

2）该对象每次只需要存取部分数据

方案1： 可以尝试将对象分拆成几个key - value， 使用multiGet获取值，这样分拆的意义在于分拆单次操作的压力，将操作压力平摊到多个redis实例中，降低对单个redis的IO影响；

方案2：可以将这个存储在一个hash中，每个field代表一个具体的属性，使用hget, hmget来获取部分的value，使用hset，hmset来更新部分属性

2、hash， set，zset，list

类似于场景一种的第一个做法，可以将这些元素分拆。 以下以以 hash 为例，set, zset, list 也可以类似上述做法

1、原先的正常存取流程是

hget(hashKey, field) ; 
hset(hashKey, field, value)

2、现在，固定一个桶的数量，比如 10000， 每次存取的时候，先在本地计算field的hash值，模除 10000， 确定了该field落在哪个key上。

newHashKey  =  hashKey + (hash(field) % 10000）;

3、使用新的hash key

hset (newHashKey, field, value) ;  
hget(newHashKey, field)

1）不适合的场景

1、要保证 lpop 的数据的确是最早 push 到 list 中去的，这个就需要一些附加的属性，或者是在key的拼接上做一些工作（比如list 按照时间来分拆）。

3、大Bitmap或布隆过滤器（Bloom ）拆分

使用bitmap或布隆过滤器的场景，往往是数据量极大的情况，在这种情况下，Bitmap和布隆过滤器使用空间也比较大，比如用于公司userid匹配的布隆过滤器，就需要512MB的大小，这对redis来说是绝对的大value了。

方案：这种场景下，我们就需要对其进行拆分，拆分为足够小的Bitmap，比如将512MB的大Bitmap拆分为1024个512KB的Bitmap。

不过拆分的时候需要注意，要将保证 一个key计算出的一系列Hash值都落在一个Bitmap上。 把所有拆分后的Bitmap当作独立的bitmap，然后通过分桶原理将不同的key分配给不同的小bitmap上，这样做后每次请求都只要在redis中一个bitmap上操作即可。

建议 ： k 取 13 个， 单个bloomfilter控制在 512KB 以下

image-20210615175822706

问题1：通过这样拆分后，相当于Bitmap变小了，会不会增加布隆过滤器的误判率？

答案：实际上是不会的，布隆过滤器的误判率是哈希函数个数k，集合元素个数n，以及Bitmap大小m所决定的。

五、key 太多

如果key的个数过多会带来更多的内存空间占用， 这两个方面在key个数上亿的时候消耗内存十分明显（Redis 3.2及以下版本均存在这个问题，4.0有优化）；

1、key本身的占用

2、集群模式中，服务端需要建立一些 slot2key 的映射关系，这其中的指针占用在key多的情况下也是浪费巨大空间

1）key 本身就有很强的相关性

比如：多个key 代表一个对象，每个key是对象的一个属性

方案：这种可直接按照特定对象的特征来设置一个新 Key——Hash 结构， 原先的 key 则作为这个新Hash 的 field。

举例： 原先存储的三个key ，

user.zhangsan-id = 123;  
user.zhangsan-age = 18; 
user.zhangsan-country = china;

这三个key本身就具有很强的相关特性，转成Hash存储就像这样

key = user.zhangsan

field:id = 123; 
field:age = 18; 
field:country = china;

即redis中存储的是一个key ：user.zhangsan， 他有三个 field， 每个field + key 就对应原先的一个key

2、key 本身没有相关性

比如现在预估 key 的总数为 2 亿，

方案：我们可以按照一个 hash 存储 100 个 field 来算，需要 2亿 / 100 = 200W 个桶 (200W 个key占用的空间很少，2亿可能有将近 20G )

举例：有三个 key （userId） ： 123456789 , 987654321， 678912345

现在按照200W 固定桶分就是先计算出桶的序号 hash(12345678) % 200W ， 这里最好保证这个 hash算法的值是个正数，否则需要调整下模除的规则；

这样算出三个key 的桶分别是 1 ， 2， 2

这里 bucket key 为了标识出来意义， 加了个前缀 userid - bucket， 不影响整体逻辑，业务自行判断

存储的时候
	原先 set (realKey, value)      
	现在 hset（bucketKey，realKey， value ），
读取的时候
	原先 get（realKey）   
	现在 hget（bucketKey， realKey）   

 
key1 : 
	hset（userid-bucket-1,  123456789 ,  value ）      
	hget（userid-bucket-1,  123456789）

key2:  
 hset (userid-bucket-2,  987654321,  value )       
 hget（ userid-bucket-2,  987654321）

key3:  
	hset（userid-bucket-2,  678912345,  value)         
	hget（userid-bucket-2,  678912345）

ContactAuthor