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长度不可控变得很长；

这下明白啥是大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；

（3）redis-rdb-tools

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

（4）集成化可视化工具

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

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

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

（1）删除/清理大key

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

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

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问题，同事们都夸他牛皮