当前位置：首页 > 问答 > 正文

Redis哈希槽怎么设置啊，感觉有点复杂但又必须得弄懂才行

邝冷亦
问答
2026-01-05 14:37:30
30

你说感觉Redis哈希槽有点复杂，这个感觉非常正常，因为它确实是Redis集群核心机制里最需要花点心思理解的部分，别担心，我们不用那些绕口的专业术语，就把它想象成一个超级市场的储物柜系统,这样就好懂多了。

第一部分：为什么要有哈希槽？——从单间到高楼大厦

最开始，Redis就像一个单间小卖部，所有商品（数据）都放在这一个房间里，顾客（客户端）来存取东西，直接找店长（单个Redis进程）就行，简单直接，但后来生意太好了，商品多得放不下，顾客也排长队，店长一个人忙不过来（单节点性能瓶颈），而且万一店长生病了，小卖部就得关门（单点故障）。

为了解决这个问题，人们决定开一家大型超市（Redis集群），这个超市有很多层楼，每层楼都有很多排储物柜（多个Redis节点），这样，商品可以分散存放，多个管理员可以同时服务，容量和效率都上去了，即使某个管理员请假，也只是他负责的那排柜子暂时不能用,不影响超市整体运营。

那么问题来了：一个顾客来存一个包裹，应该放进哪个柜子呢？如果随便放，下次来找的时候就得翻遍整个超市，这太慢了，我们必须有一个又快又准的规则，让顾客和管理员都能瞬间知道包裹在哪，这个规则，就是哈希槽。

哈希槽的本质，是Redis集群用来分配和管理数据到底存储在哪个节点上的一套规则，它就像那个储物柜系统的“寻址指南”。

第二部分：哈希槽是怎么工作的？——储物柜的编号规则

Redis集群默认设置了16384个哈希槽（slot），你可以把它们想象成超市里编号从0到16383的虚拟小格子，这些槽是逻辑上的概念，并不真的对应物理上的16384个柜子，真正的储物柜（物理节点）是来“认领”这些槽的。

分配槽位给节点：在搭建集群时，我们会告诉Redis，这16384个槽分别由哪几个节点（比如3个主节点）来负责管理，可以平均分配，比如节点A管0-5460号槽，节点B管5461-10922号槽，节点C管10923-16383号槽，也可以不平均，但必须确保所有槽都被分配出去，这个过程就是“设置哈希槽”。（来源：Redis官方文档关于集群数据分片的说明）
计算数据该去哪个槽：当你要存储一个数据时，比如set user:1001 "张三"，Redis集群会怎么做呢？它会拿这个数据的键（key），也就是user:1001，去做一个简单的计算：CRC16算法校验和 % 16384，你不用管CRC16是啥，就把它理解为一个黑盒子，输入一个字符串（key），它总会输出一个0到16383之间的固定数字，比如user:1001算出来是5000,那么这个键值对就应该放到5000号槽里。
定位节点并执行命令：由于我们已经知道5000号槽是由节点A管理的，所以这个set命令最终会被导向节点A去执行，下次你要读取user:1001，集群同样会计算key得到5000,然后直接去问节点A要数据。

这样一来，无论集群有多少个节点，对于任何一条数据，我们都能在O(1)的时间复杂度内（也就是瞬间）确定它应该在哪个节点上，这就解决了“寻址”的核心难题。

第三部分：哈希槽的妙处——灵活性与高可用性

这个设计有几个非常聪明的地方：

解耦数据与节点：数据和具体的物理节点没有直接绑定，而是通过槽这个中间层关联，这带来了极大的灵活性，超市生意更好了，需要增加一层楼（扩容，增加一个新节点），我们不需要把所有的商品重新整理一遍，我们只需要从原来三个管理员负责的槽位里，每人拿出一部分（比如各拿出1000个槽），分配给新来的管理员，只需要移动这3000个槽对应的实际商品数据即可，整个超市大部分区域照常营业，影响很小，缩容（减少节点）也是同样的道理，这个过程就是Redis集群的重分片。（来源：Redis官方文档关于集群重新分片的说明）
保证命令执行：有些命令涉及到多个key，比如MSET a 1 b 2，如果key a和key b经过计算后发现不在同一个哈希槽上，这个命令就会执行失败，因为集群模式下，Redis要求能在一个节点上完成的事务，必须在一个节点上完成，不能跨节点执行，这会带来一些使用上的约束，但却是保证集群简单性和性能的必要代价，对于需要多key操作的场景，你可以使用“哈希标签”（hashtag），即用把key中相同的部分括起来，比如user:{1001}和profile:{1001}，这样集群在计算槽位时只会看内的内容,确保它们落在同一个槽里。
故障转移：在集群中，每个负责槽的主节点都可以有一个或多个从节点（副本），如果主节点A宕机了，集群会自动选举它的一个从节点升级为新的主节点，并接管之前A负责的所有哈希槽，这样，服务在秒级内就能恢复，只是那些槽的数据会有一个短暂不可用的时期,这就是集群的高可用性。