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

前言

前几天端午节，小黑准时下班回到家，吃着粽子，看着电视，好生惬意！忽然，手机叮咣叮咣响个不停报警，看了下是某个服务调用 Redis 异常了。

放下饭碗，小黑打开电脑一顿排查，最终定位到是 Redis 有大 key 问题。寻思一时半会儿也解决不了，明天到公司再搞，先继续看电视吧。

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

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

这样就对上了，key 往往是程序可以自行设置的，value 往往不受程序控制，因此可能导致 value 很大。

设想一种场景：

在线音乐 App 中，某个歌单有很多用户收藏，假如有这样的数据结构：

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

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

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

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

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

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

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

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

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

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

redis-rdb-tools 是用 Python 编写的 Redis rdb 快照文件分析工具，它可以把 rdb 快照文件生成 JSON 文件，或者生成报表用来分析 Redis 的使用详情。

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

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

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

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

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

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

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