最近,项目上线的时候,出现了一个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
例如以下这些操作:
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)