Redis大Key分析和解决最佳实践

尊龙时凯

刘彬

1.

概述

我们先假定有如下场景：某税务局一线运维收到客户反馈通知，
，，
，说系统查询某机构对申报信息极为缓慢。。。于是开发人员找到一个出问题的机构A
，，，，通过搜索日志系统找到系统操作Redis时间比较久，，，并且从日志系统搜到一些Redis 含询超时的异常。。。。最后我们定位到的原因如下：

在申报接口的时候系统通过Redis做了一个级存，，，记录机构的申报信息，，Redis数据结构：key=机构、、、、IDvalue=申报列表，，，而Redis查询发现多了许多大key，，
，，体现在一个机构ID一天有上万甚至几十万的申报信息。。。
。我们通常将此类问题称为Redis大Key问题
。。。。

2.

Redis大Key基本概念及场景

所谓的大key问题是某个key对应的value比较大
，，，，所以本质上是大value问题，，，key往往是开发过程中可以自行设置，，可以控制大小
，，，，value往往不受程序控制跟业务场景有关系，，
，
，因此可能导致value较大。
。。

2.1基本概念

在Redis中，，，大key指的是key对应的value值所占的内存空间比较大：

● value是string类型，，大小建议控制在10kb以内。。
。

● valve是hash
、
、list、、、set、、、zset等集合类型，
，，元素个数建议不要超过 5000（或者1万、、、、几万）。。。。上述的定义并不绝对，，，主要是根据value的大小和元索个数来确定，，业务也可以很据自己的场景确定标淮。。

2.2常见场景

大key的产生往往是业务方设计不合理，，，，没有预见vaule的动态增长问题。。。。

通常有几类此较经典的场录：

● 一直往value存放数据，，，没有删除及过期机制。
。。。

● 数据没有合理做分片，，，将大key变成以一个个小key。。

3.

Redis大Key带来的影响

● 客户端超时阻塞。。由于Redis单线程的特性，，，操作大key的通常比较耗时，，也就意味着阻塞Redis可能性越大
，
，，，这样会造成容户瑞阻塞或者引起故障切换，
，
，会出现各种Redis慢查询。。
。。

● 内存空间不均匀。。。集群模式在slot分片均匀情况下，，，会出现数据和查询倾斜情况
，
，，部分有大key的Redis节点占用内行多、、、、QPS高。。。

● 引发网络阻塞。。每次获取大key产生的网络流量按大
，，，如果一个key的大小为1MB每秒访问量为1000，，，，那么行秒会产生1000MB的流量。。这对于普通千兆网卡的服务器说是灾难性的。。

● 阻塞工作线程。。。。执行大key删除时，，，在低版本Redis中可能阻塞线程。
。。。

4.

Redis大Key如何检测

● 改写Redis客户端，，，在sdk中加入埋点，，实时上报数据给Redis大key 检测平台、、、、监控告警。。。。

● scan+debug object bigkey命令，
，循环遍历Redis key序列化后的长度
。
。
。。debug object bigkey可能会比较慢，，，，它存在阻塞Redis的可能，，建议在从节点执行该命令，
，官方不推荐
。。。

● scan+memory usage。。
。该命令是在Redis 4.0+以后提供的，，，可以循环遍历统计计算每个键值的字节数。。
。。

● 通过python脚本迭代的scan key
。。对每次scan的内容进行判断是否为大key。。。

● Redis-cli --bigkeys。
。。。可以找到某个Redis 实例5种数据类型（string
、
、、、hash、
、list、、、set、、zset）的最大key。
。。。但如果Redis key 比较多，，执行该命令会比较慢，，
，建议在从节点执行该命令。。
。。

● rdbtools开源工具包。。
。
。rdbtools是python写的一个第三方开源工具
，，，用来解析Redis快照文件，，，，Redis实例上执行bgsave
，，，
，然后对dump出
；来的rdb文件进行分析，，，找到其中的大key。。
。

例如：rdb dump.rdb -c memory --byes 10240 -f Redis.csv

从dump.rdb 快照文件统计 (bgsave)，，，将所有＞10kb的key输出到一个csv文件。。。。

5.

Redis大Key如何删除

如果对这类大key直接使用del命今进行删除，，，，会导致长时间阻塞
，，甚至崩溃，，，，因为del命令在删除集合类型数据时
，，时间复杂度为O(M)
，，M是集合中元素的个数。。。Redis是单线程的
，
，单个命令执行时间过长就会阻塞其他命令，，容易引起雪崩
，，稳妥的建议如下：

主动删除大Key

一、、
、、分批次渐近删除

一般来说，，，，对于string数据类型使用del命令不会产生阻塞。
。其它数据类型分批删除
，，
，，通过scan命令遍历大key，，每次取得少部分元素进行删除，，，
，然后再获取和删除下一批元素．对Hash,Sorted Set, List. Set 分别处理
、、、思路相同，，，先对key改名进行逻辑删除，，使客户端无法使用原key
，，
，，然后使用批量小步删除。。

● 删除大Hash

步骤：（1）key改名，，，相当于逻辑上删除key，，，任何Redis命令都访问不了该key。。（2）小步多批次删除。。
。

伪代码：

● 删除大List

伪代码
：

● 删除大Set

伪代码：

● 删除大Sorted Set

伪代码：

二、
、、
、采用unlink+bigkey异步非阻塞删除，，，，这个命令是在Redis 4.0+提供的代替del命令
，，不会阻塞主线程。。

被动删除大Key

被动删除是指利用Redis自身的key消除策略，，
，配置lazyfree情性删除。。。。但是参数默认是关闭的。。可配置如下参数开启
：

6.

Redis大Key如何设计与优化

主要针对以下两种经典场景进行优化
：

单个key 存储的 value 很大（超过 10kb)

1）从业务角度评估
，
，value中只存储有用的字段
，
，尽量去掉无用的字段。
。。。

2）可以考点在应用层先对value进行压缩，，比如采用LZ4/Snappy之类的压缩算法，，配合Redis客户端序列化配置，，，可以无侵入完成value的压缩。。.

3）value设计的时候越小越好，，，关联的数据分不同的key进行存儲。。。。

4）大key分拆成几个key-value
，，，，使用multiGet获取值，，这样分拆的意义在于分拆单次操作的压力．将操作压力拼摊到多个Redis实例中，
，，，降低对单个Redis的IO影响。。。。

5）对Redis集群进行扩容
。。
。

集合数据类型hash. list, set. sorted set等存储过多的元素（超过5000个）

类似于场景一中的第一个做法，，，，可以将这些元素分拆
：

以hash为例，，，原先的正常存取流程是hget(hashKey,field) ;hset(hashkey,field,value)现在，，
，
，我们可以分拆构建一个新的 newHashkey，，具体做法：固定一个桶的数量，，比如10000每次存取的时候，，先在本地计算field的hash值，，，，取模10000，，
，确定了该field落在哪个newHashkey上
。。

set、、sorted
、、、list也可以采用类似做法。。