Redis报错：CROSSSLOT Keys in request don‘t hash to the same slot的解决方案

最近，项目上线的时候，出现了一个Redis的报错：CROSSSLOT Keys in request don't hash to the same slot，这个在内网环境下无法复现，因为正式环境的Redis是cluster集群模式，而我们内网环境是单机模式。(后面我在内网也部署了一个Redis集群，具体见我这一篇文章《使用Docker搭建Redis Cluster集群》）

Redis集群的slot概念

Redis的插槽(Slot)是用于实现集群分片(Cluster Sharding)的一种机制。Redis集群至少需要三个结点，每个结点处理一部分数据。那么怎样分配这些数据到各个结点呢？Redis Cluster 采用的是虚拟槽分区算法，其中提到了槽（Slot）的概念。这个槽是用来存放缓存信息的单位，在 Redis 中将存储空间分成了 16384 （ 2 14 {2}^{14} 214）个槽，也就是说 Redis Cluster 槽的范围是 0 -16383。

在存储数据的时候，集群会对 Key 进行 CRC16 校验并对 16384 取模：

slot = CRC16(key) % 16384

得到的结果就是 Key-Value 所放入的槽，从而实现自动分割数据到不同的节点上

为什么会是16384个插槽呢？Redis作者是这么说的：传送门

什么情况下会报这个错

在集群模式下，所有涉及到多个 key的Redis指令，都要求所有的 key处于同一个 slot，如果 slot不同，哪怕实际上这些 slot都在同一个结点上，也会报这个错：

CROSSSLOT Keys in request don't hash to the same slot

例如以下这些操作：

redis 复制代码

SUNIONSTORE destination key [key ...]
 SDIFF key [key ...]
 EVAL script numkeys key [key ...] arg [arg ...]
 DEL key [key ...]

只要看到格式中有 key [key ...]这样的操作，在集群中，都必须保证所有 key在同一个 slot。

禁止不同的slot操作，大概有以下原因：

性能考虑：允许跨槽操作将需要在不同节点之间进行复杂的协调和网络通信，这可能会显著降低操作的性能。Redis设计为高性能的存储系统，这种设计选择有助于保持操作的速度和效率。
简化分布式环境下的操作：通过限制操作仅在相同槽的键上执行，Redis Cluster简化了分布式环境下的数据管理。这样做减少了数据一致性和同步问题的复杂度，使得集群管理更为简单。
提高可扩展性和可靠性：这种设计允许Redis Cluster在节点失败或网络分区发生时更容易地进行数据迁移和故障转移。如果允许跨槽操作，这将增加数据迁移和恢复的复杂性，可能会影响到整个系统的可靠性。
分区的自治性：将数据划分到不同的槽中，并限制跨槽操作，有助于保证每个分区的自治性。这意味着每个节点可以独立处理其槽内的操作，从而减少了节点之间的依赖性。

要如何解决这个问题

既然Redis集群不允许跨slot的操作，那我们只要让key强制分配到同一个Slot就行了。

上面说了，正常情况下，slot = CRC16(key)%16384，这里是对整个key进行CRC16。

Redis提供了一种Hash Tag 的功能，在key中使用{}括起key中的一部分，在进行 CRC 16 (key) % 16384 的过程中，只会对{}内的字符串计算。

例如，{rank:level}:1,{rank:level}:2这两个key就会分配都同一个slot，因为计算哈希的时候，都使用了 {}中的那一部分:rank:level，所以分配出来的 slot就是一样的。

值得注意的是，这里的 {}可以放在key的任意位置，例如 all{rank:level},all{rank:level}:1也都是一样的。

另外，如果有多个 {}的话，只有第一个 {}生效，例如 {rank:level}:1:{2}，用来计算哈希的只是第一个 {}里面的 rank:level

参考资料

[CSDN]Redis中的插槽(slot)