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

前言

前几天元宵节，小黑准时下班回到家，吃着汤圆，看着电视，好生惬意！

忽然，手机叮咣叮咣响个不停报警，看了下是某个服务调用Redis异常了。

放下饭碗，小黑打开电脑一顿排查，最终定位到是Redis有大key问题。

寻思一时半会儿也解决不了，明天到公司再搞，先继续看电视吧 哈哈哈。

什么是大key

很多朋友肯定在想redis的key能有多大呀？

这里就有个误区了，所谓的大key问题是某个key的value比较大，所以本质上是大value问题。

设想一种场景：

• 歌单和用户之间的映射关系采用redis存储
• redis的key是歌单ID，长度可控且很小
• redis的value是个list，list包含了用户ID
• 用户可能很多，就导致list长度不可控

这下明白啥是大key问题了吧！

redis中有常见的几种数据结构，每种结构对大key的定义不同，比如：

• value是String类型时，size超过10KB
• value是ZSET、Hash、List、Set等集合类型时，它的成员数量超过1w个

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

大key有什么影响

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

单线程中请求任务的处理是串行的，前面完不成，后面处理不了，同时也导致分布式架构中内存数据和CPU的不平衡。

• 执行大key命令的客户端本身，耗时明显增加，甚至超时
• 执行大key相关读取或者删除操作时，会严重占用带宽和CPU，影响其他客户端
• 大key本身的存储带来分布式系统中分片数据不平衡，CPU使用率也不平衡
• 大key有时候也是热key，读取操作频繁，影响面会很大
• 执行大key删除时，在低版本redis中可能阻塞线程

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

大key是如何产生的

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

• 一直往value塞数据，没有删除机制，迟早要爆炸
• 数据没有合理做分片，将大key变成小key

如何找到大key

• 增加内存&流量&超时等指标监控

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

• bigkeys命令

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

• redis-rdb-tools

使用redis-rdb-tools离线分析工具来扫描RDB持久化文件，虽然实时性略差，但是完全离线对性能无影响。

• 集成化可视化工具

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

如何解决大key问题

根据大key的实际用途可以分为两种情况：可删除和不可删除。

删除大key

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

• 当Redis版本大于4.0时，可使用UNLINK命令安全地删除大Key，该命令能够以非阻塞的方式，逐步地清理传入的Key。

• 当Redis版本小于4.0时，避免使用阻塞式命令KEYS，而是建议通过SCAN命令执行增量迭代扫描key，然后判断进行删除。

压缩和拆分key

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

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

• 当value是list/set等集合类型时，根据预估的数据规模来进行分片，不同的元素计算后分到不同的片。

小结

Redis的大key问题，无论在面试还是工作中都很常见，好好理解一波，非常值得。

祝各位老铁 深夜无报警，线上无bug！