怎么解决 Redis 中数据倾斜的问题？

这里我要先解释一下数据倾斜，数据倾斜一般是指某个地方的数据要比别的地方多。

具体到 Redis 这里，就是 Redis 的某些节点上的数据明显比别的节点多。而正常来说，数据倾斜了，QPS 也倾斜了。所以这些比较多数据的节点，QPS 也会更高。所以这些节点面临 CPU、内存、网络带宽等多方面的问题。

而且，如果是 QPS 很高，业内也把这个问题叫做热点问题。

所有的数据倾斜的解决思路只有一个：分而治之。也就是把这些集中的数据重新打散，分散到别的地方。

那么在 Redis 这里，按照这个思路，可以有很多种解决方案：

• 挪走一部分业务数据。举个例子来说，如果 User 和 Order 共用一个 Redis Cluster，然后 User 导致某个节点数据倾斜了，那么可以将 User 改为使用另外一个 Redis Cluster；
• 槽迁移：挑一个业务低峰期，执行 Redis Cluster 的 rebalance，简单好用，优先使用。当然也可以自己手动分配槽，而后迁移走槽；
• 增加 Redis 节点：加了 Redis 节点之后，肯定会重新分配槽，所以至少会迁走一部分倾斜的数据，效果也很不错；
• 重新设计 key 结构：举个例子，假设说原本的 key 结构是 user:$id，那么可以考虑改改前缀，比如说 /my/company/user/$id。虽然你看上去只是改了前缀，但是经过 CRC16 之后算出来的哈希值跟原版会有很大差异；
• 手动哈希一次：例如说 user:$id 是原始的 key，你可以改为用 user:md5($id) 来作为key，也可以用 md(user:$id)，小心设计不要重复了。当然你可以把 md5 换成别的算法，核心就是经过手动哈希之后，你的 key 落到节点上会更加均匀；
• 拆分 key。也就是如果数据迁移是因为某些大的数据结构造成的，比如说 user:all 这个 key 放了 1000w 个元素，那么可以考虑 拆分成 user:all_0, user:all_1... user:all_n 多个key，那么这些 key 大概率不会都落在同一个节点上；

手动哈希这个我再举几个例子，假设说你选择的哈希函数叫做 new_hash:

new_hash(user:$id)
user:new_hash($id)
user:$id:new_hash($id)

这个是非常灵活的，你不要那么死板。注意选择之后数据是否均匀，生成的最终的 key 会不会冲突。

其中，我建议你至少要能回答出来挪走业务数据、槽迁移和增加Redis节点三个。后面的重新设计 key 结构和手动哈希是比较奇诡的做法，但是能刷出亮点，最后的拆分 key 是为了引出解决大 key 的问题。

注意，如果面试官 Redis 如何解决热点问题，你也可以参考这个回答。