Redis 中如何排查大 Key 问题？

所谓的大 key，不是指 key 本身很长，而是指值很大，比如说一个巨大的 JSON 串，一个巨大的 zset，list 等。大 key 一般会引起数据倾斜、QPS 倾斜等问题。或者说大 key 有极大的可能是热点 key，并发极高。

在这之前，你可以先看这些问题，它们有些类似，但是又很不同：

• 怎么解决 Redis 中数据倾斜的问题？
• 如果 Redis Cluster 上某个节点的并发非常高，怎么办？
• 如果 Redis Cluster 上的某个槽的 QPS 非常高，怎么办？

大 key 其实就有一个解决方案，分而治之。也就是拆分 key。比如说原本一个 key 对应的 list，放了 100w 数据，那么可以拆成 100 个 key，每个 key 只有 1w 数据。

你在 Redis 这个场景下，要考虑不同的数据结构分 key 怎么分，假定这里都是分成 10 个key。基本的拆分思路有两个：

• 按照哈希来拆分。例如说 list 中的元素值是 103，那么拆分后它应该在 103%3 = 3 key3 中。如果是哈希结构，则按照哈希结构的 key 来进一步哈希拆
• 按照值的范围来拆分。例如说 list 中的元素的值是 103，那么拆分后它应该在 [100, 200) 这一段中，假设说是 key1。

除了这些通用的拆分方法，还有一些独特的拆分方法：

• 按照业务来拆分。比如说一个 User 的全部存储在一个哈希结构里面，你就可以将基本信息，登录信息拆分成两个 key；
• 按照 QPS 来分。比如说 list 中有 10w 个元素，你要拆成 10 个 key，你就要保证这个 10 个 key 的 QPS 是接近的，而不是直接平均分 10w；

而后，你要关注的就是拆分后怎么解决具体的业务问题了。

而这里，也有一个拆分 key 的典型的案例，你可以查看：Redis 数据结构：榜单问题之 zset 拆分解决方案。这个案例能够体现出拆分 key 之后额外引入的复杂度。

这里也有一些例外，比如说存储大 JSON 串的时候，可以考虑用哈希结构来优化，你可以参考这个案例：Redis JSON 串转哈希存储。核心思想也是分而治之，只不过是将存取一个完整的 JSON 串改为操作部分 key 而已。