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}$ ）个槽，也就是说 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

例如以下这些操作：

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在节点失败或网络分区发生时更容易地进行数据迁移和故障转移。如果允许跨槽操作，这将增加数据迁移和恢复的复杂性，可能会影响到整个系统的可靠性。
分区的自治性：将数据划分到不同的槽中，并限制跨槽操作，有助于保证每个分区的自治性。这意味着每个节点可以独立处理其槽内的操作，从而减少了节点之间的依赖性。