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也可以采用类似做法。。
