Redis——大Key问题

╰+攻爆jí腚メ 2023-09-28 09:00 157阅读 0赞

上一篇文章讲了[Redis的热点key问题][Redis_key]，本篇介绍Redis大Key问题的概念，大Key问题产生的原因、危害以及解决大Key问题的思路；

#### 1. 什么是大key？多大算大key？ ####

其实关于"大key"这个名词，这里就有个误区了，**所谓的大key问题是指某个key的value比较大，所以本质上是大value问题**；这样就对上了，key往往是固定的，一般根据key前缀和业务属性拼接而成，而value往往不是固定的，在服务运行期间被修改，因此是可能导致value变得很大的；

设想一种场景，在线音乐APP中，某个歌单有很多用户收藏，假如有这样的数据结构：

*  歌单和用户之间的映射关系采用redis存储；
 *  redis的key是歌单ID，长度可控且很小；
 *  redis的value是个List，List包含了关注了该歌单的用户ID；
 *  用户可能很多，如果该key要存放所有关注歌单的用户ID，就会导致List长度不可控变得很长；

![3778aebb49f440b5aad78a9b4e4bf687.png][]这下明白啥是大key问题了吧!

**到底多大的value认为是大key呢？**

Redis中有常见的几种数据结构，每种结构对大key的定义不同，通常以Key的大小和Key中成员的数量来综合判定，例如：

*  key本身的数据量过大：value是String类型时，Value 的字节大小大于10 KB；
 *  key中的集合元素数过多：value是ZSET、Hash、List、Set等集合类型时，它的成员数量超过1w个；
 *  Key中成员的数据量过大：一个Hash类型的Key，它的成员数量虽然只有1,000个但这些成员的Value（值）总大小为100 MB

上述的定义并不绝对，主要是根据value的成员数量和value的字节数来确定，业务可以根据自己的场景也确定标准；

#### 2. 大key的危害？ ####

我们都知道，Redis的一个典型特征就是：核心工作线程是单线程。

单线程中请求任务的处理是串行的，前面完不成，后面处理不了，同时也导致分布式架构中内存数据和CPU的不平衡；因此Redis的大key可能带来以下问题：

*  执行大key命令的客户端本身，耗时明显增加，甚至超时；
 *  Redis内存达到maxmemory参数定义的上限，引发操作阻塞或重要的Key被逐出，甚至引发内存溢出（Out Of Memory）。
 *  执行大key相关读取或者删除操作时，会严重占用**带宽**和**CPU**，影响服务器上的其他客户端；
 *  集群架构下，大key本身的存储带来分布式系统中分片数据不平衡，，CPU使用率也不平衡，某个数据分片的内存使用率远超其他数据分片，无法使数据分片的内存资源达到均衡
 *  大key有时候也是热key，读取操作频繁，影响面会很大
 *  执行大key删除时，在低版本redis中可能易造成主库较长时间的阻塞，进而可能引发同步中断或主从切换；

这样看来大key的影响还是很明显的，最典型的就是：阻塞线程、并发量下降、导致客户端超时、服务端业务成功率下降；

#### 3. 大key一般是如何产生的？ ####

大key的产生往往是业务方设计不合理，没有预见vaule的动态增长问题；造成大key问题的原因一般有：

*  在不适用的场景下使用Redis，易造成Key的value过大，如使用String类型的Key存放大体积二进制文件型数据；
 *  业务上线前规划设计不足，没有对Key中的成员进行合理的拆分将大key变成小key，从而造成个别Key中的成员数量过多；
 *  集合类数据结构一直往value里面塞数据，没有删除机制，未定期清理无效数据，造成如HASH类型Key中的成员持续不断地增加；
 *  使用LIST类型Key的业务消费侧发生代码故障，造成对应Key的成员只增不减；

#### 4. 如何发现大key？ ####

**（1）增加内存&流量&超时等指标监控**

由于大key的value很大，执行读取时可能阻塞线程，这样Redis整体的QPS会下降，并且客户端超时会增加，网络带宽会上涨，配置这些报警可以让我们发现大key的存在；

**（2）bigkeys命令**

使用bigkeys命令以遍历的方式分析Redis实例中的所有Key，并返回整体统计信息与每个数据类型中Top1的大Key；

![8e4c89e4467f4426b1c537ca55569e4e.webp][]

**（3）redis-rdb-tools**

[Redis-rdb-tools][]是通过Python编写，支持定制化分析Redis RDB快照文件的开源工具；使用redis-rdb-tools离线分析工具来扫描RDB持久化文件，虽然实时性略差，但是完全离线对性能无影响；

**（4）集成化可视化工具**

基于某些公有云或者公司内部架构的redis一般都会有可视化的页面和分析工具，来帮助我们定位大key，当然页面底层也可能是基于bigkeys或者rdb文件离线分析的结果；

![9adfea64f157414ca6810b660157bc25.webp][]

#### 5. 处理大key问题的思路？ ####

根据大key的实际用途可以分为两种情况：可删除和不可删除；解决思路如下图：

![5f75be3fddc54f7e9c25a28ab8436b57.webp][]

**（1）删除/清理大key**

如果发现某些大key并非热key就可以在DB中查询使用，则可以在Redis中删掉；

*  当Redis版本大于4.0时，可使用UNLINK命令安全地删除大Key，该命令能够以非阻塞的方式，逐步地清理传入的Key；
 *  当Redis版本小于4.0时，避免使用阻塞式命令KEYS，而是建议通过SCAN命令执行增量迭代扫描key，然后判断进行删除；

![8b87099babb040f2aa9ae763f1533d45.webp][]

Redis UNLINK 命令类似与 DEL 命令，表示删除指定的 key，如果指定 key 不存在，命令则忽略；UNLINK 命令不同与 DEL 命令在于它是异步执行的，因此它不会阻塞；UNLINK 命令是非阻塞删除，非阻塞删除简言之，就是将删除操作放到另外一个线程去处理；

Redis Scan 命令用于迭代数据库中的数据库键；SCAN 命令是一个基于游标的迭代器，每次被调用之后， 都会向用户返回一个新的游标， 用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数， 以此来延续之前的迭代过程；

**对过期数据进行定期清理**

堆积大量过期数据会造成大Key的产生，例如在HASH数据类型中以增量的形式不断写入大量数据而忽略了数据的时效性；可以通过定时任务的方式对失效数据进行清理；在清理HASH数据时，建议通过HSCAN命令配合HDEL命令对失效数据进行清理，避免清理大量数据造成Redis阻塞；

**（2）压缩和拆分key**

a. 当vaule是string时，比较难拆分，则使用序列化、压缩算法将key的大小控制在合理范围内，但是序列化和反序列化都会带来更多时间上的消耗；

b. 当value是string，压缩之后仍然是大key，则需要进行拆分，一个大key分为不同的部分，记录每个部分的key，使用multiget等操作实现事务读取。

c. 当value是list/set/hash等集合类型时，根据预估的数据规模来进行分片，不同的元素计算后分到不同的片；在Redis集群架构中，拆分大Key能对数据分片间的内存平衡起到显著作用；

**（3）监控Redis的内存水位**

可以通过监控系统设置合理的Redis内存报警阈值进行提醒，例如Redis内存使用率超过70%、Redis的内存在1小时内增长率超过20%等；通过此类监控手段，可以提前规避许多问题，例如LIST数据类型的消费程序故障造成对应Key的列表数量持续增长，将告警转变为预警从而避免故障的发生；

参考：

[发现并处理Redis的大Key和热Key - 云数据库 Redis - 阿里云][Redis_Key_Key - _ Redis -]

[解决了Redis大key问题，同事们都夸他牛皮][Redis_key 1]

[Redis_key]: https://blog.csdn.net/minghao0508/article/details/123972442
[3778aebb49f440b5aad78a9b4e4bf687.png]: https://img-blog.csdnimg.cn/3778aebb49f440b5aad78a9b4e4bf687.png
[8e4c89e4467f4426b1c537ca55569e4e.webp]: https://img-blog.csdnimg.cn/8e4c89e4467f4426b1c537ca55569e4e.webp
[Redis-rdb-tools]: https://github.com/sripathikrishnan/redis-rdb-tools
[9adfea64f157414ca6810b660157bc25.webp]: https://img-blog.csdnimg.cn/9adfea64f157414ca6810b660157bc25.webp
[5f75be3fddc54f7e9c25a28ab8436b57.webp]: https://img-blog.csdnimg.cn/5f75be3fddc54f7e9c25a28ab8436b57.webp
[8b87099babb040f2aa9ae763f1533d45.webp]: https://img-blog.csdnimg.cn/8b87099babb040f2aa9ae763f1533d45.webp
[Redis_Key_Key - _ Redis -]: https://help.aliyun.com/document_detail/353223.html
[Redis_key 1]: https://www.51cto.com/article/701990.html