Redis哈希槽

在Redis高可用架构中，集群（Redis Cluster）是应对大规模数据存储和高并发访问的终极方案，而支撑集群实现“数据分布式存储”和“水平扩展”的核心机制，正是哈希槽（Hash Slot）。

一、先搞懂：为什么集群需要哈希槽？

在了解哈希槽之前，我们先思考一个问题：Redis集群由多个节点组成，当我们执行SET key value时，数据该存到哪个节点？如果没有一套高效的分配机制，会出现“数据集中在某个节点导致过载”“新增节点后数据迁移复杂”等问题。

哈希槽就是为解决这些问题而生的，它的核心定位是：作为Redis集群中“数据与节点”之间的中间映射层，实现数据的均匀分布和灵活迁移。

1.1 没有哈希槽会怎样？

如果直接通过“键的哈希值对节点数量取模”来分配数据（比如3个节点，键哈希后%3决定存哪个节点），会存在两个致命问题：

1. 水平扩展困难：新增或删除节点时，节点数量变化，所有键的映射关系都会失效，需要重新计算所有键的存储节点并迁移数据，成本极高；
2. 数据分布不均：如果键的哈希值分布不均匀，会导致部分节点存储大量数据，出现“热点节点”，无法实现真正的负载均衡。

而哈希槽通过“固定槽位数量+槽与节点绑定”的方式，完美解决了这两个问题。

面试得分点：开篇先讲“哈希槽的存在意义”，而不是直接定义，能体现你从“问题出发”的技术思维，比单纯背概念更加分。

二、核心概念：哈希槽是什么？

Redis集群预先定义了16384个哈希槽（编号从0到16383），这是一个固定值，不会随节点数量变化而改变。

哈希槽的核心逻辑可以概括为三句话：

• 所有哈希槽在集群节点之间分配，每个节点负责管理一部分槽位；
• 每个键通过哈希计算映射到一个具体的槽位；
• 键最终存储在“负责该槽位的节点”上。

比如集群有3个节点，可能的槽位分配是：节点A负责0-5460，节点B负责5461-10922，节点C负责10923-16383（这是Redis默认的平均分配方式）。当一个键映射到槽位12345时，就会存储到节点C上。

2.1 为什么是16384个槽？

这是面试中最常被追问的细节之一，答案需要从“性能”和“集群规模”两个维度分析：

1. 性能优化：Redis集群节点之间通过“Gossip协议”交换槽位信息，16384个槽位对应的“槽位分配表”很小（仅需2KB左右，用位图存储，每个槽位占1bit），节点之间传输和同步成本极低，不会给网络带来负担；
2. 集群规模适配：16384个槽位足够支撑中小型集群（一般Redis集群节点数量不会超过1000个），每个节点平均可分配16个以上的槽位，能保证数据分布均匀。如果槽位数量过多（如65536），会导致槽位分配表变大，同步效率降低；如果过少（如1024），则无法实现精细的负载均衡。

简单来说：16384是“槽位同步效率”和“集群扩展能力”的最优平衡。

三、工作原理：键如何找到自己的“家”？

哈希槽的工作流程非常清晰，核心分为“键映射到槽”和“槽绑定到节点”两步，整个过程无需人工干预，由Redis集群自动完成。

3.1 第一步：键通过哈希计算映射到槽位

当执行写命令（如SET）或读命令（如GET）时，Redis会先对键进行哈希计算，得到对应的槽位编号，具体步骤是：

1. 对键执行CRC16算法，得到一个16位的哈希值（范围0-65535）；
2. 将哈希值对16384取模（hash % 16384），得到0-16383之间的槽位编号。

用公式表示就是：槽位编号 = CRC16(key) % 16384

3.2 第二步：根据槽位找到对应的节点

Redis集群中的每个节点都会维护一份“槽位-节点”的映射表，记录每个槽位由哪个节点负责。当得到键对应的槽位后，Redis会通过以下方式定位节点：

1. 客户端发送命令时，会先连接集群中的任意一个节点（称为“接入节点”）；
2. 接入节点根据自己的“槽位-节点”映射表，判断该槽位是否由自己负责：
   如果是自己负责，直接执行命令；
3. 如果不是，返回“MOVED”重定向指令，告诉客户端“该槽位由哪个节点负责”，并提供目标节点的IP和端口；
4. 客户端收到重定向指令后，重新连接目标节点并执行命令（后续对该键的操作会直接连接目标节点，无需再次重定向）。

3.3 实例演示：一个键的完整存储流程

假设Redis集群有3个节点（A：0-5460，B：5461-10922，C：10923-16383），执行SET user:100 zhangsan，流程如下：

1. 客户端连接节点A（接入节点），发送SET命令；
2. 节点A对键“user:100”执行CRC16算法，得到哈希值假设为22345；
3. 计算槽位：22345 % 16384 = 5961；
4. 节点A查看映射表，发现槽位5961由节点B负责，返回“MOVED 5961 192.168.1.2:6379”（节点B的IP和端口）；
5. 客户端连接节点B，重新发送SET命令；
6. 节点B确认槽位5961由自己负责，执行命令并存储数据。

注意：Redis集群的“重定向”是客户端层面的，接入节点仅提供目标节点信息，不会转发命令，这样能减少节点之间的通信开销。

四、关键操作：哈希槽的分配与迁移

哈希槽的灵活性体现在“槽位可以在节点之间分配和迁移”，这是实现集群“水平扩展”和“负载均衡”的核心。

4.1 初始分配：集群搭建时的槽位分配

在搭建Redis集群时，需要将16384个槽位分配给各个节点，有两种常见方式：

1. 自动分配：使用Redis提供的redis-cli --cluster create命令搭建集群时，Redis会自动将槽位平均分配给所有主节点。例如3个主节点，每个节点分配5461个槽位（16384/3≈5461）；
2. 手动分配：通过redis-cli --cluster add-node命令新增节点后，使用redis-cli --cluster reshard命令手动指定槽位范围分配给新节点，适合需要自定义槽位分配的场景（如某些节点配置更高，可分配更多槽位）。

4.2 动态迁移：集群扩展或负载均衡时的槽位调整

当集群需要新增节点（扩容）、删除节点（缩容），或某个节点负载过高时，需要将部分槽位从一个节点迁移到另一个节点，整个迁移过程是“在线无感”的，不会影响集群对外提供服务。

迁移的核心步骤

1. 发起迁移请求：使用redis-cli --cluster reshard命令，指定源节点、目标节点和要迁移的槽位数量；
2. 槽位数据迁移：目标节点向源节点发送“迁移槽位”请求，源节点将该槽位下的所有键逐一迁移到目标节点，并同步给对应的从节点；
3. 更新映射表：迁移完成后，源节点释放该槽位，目标节点接管该槽位，并通过Gossip协议将“槽位-节点”的新映射关系同步给集群中所有节点；
4. 客户端感知：客户端后续访问该槽位的键时，会通过重定向连接到新的目标节点。

迁移的核心优势

哈希槽迁移的最大优势是“粒度细”——可以只迁移部分槽位，而不是整个节点的数据，这样能实现“按需扩容”和“精准负载均衡”。例如某个节点存储了大量热点数据，可将该节点的部分槽位迁移到其他节点，降低其负载。

五、哈希槽的核心作用：不止是数据分配

哈希槽不仅实现了数据的分布式存储，更支撑了Redis集群的多个核心能力，总结起来有三大作用：

5.1 实现数据均匀分布，避免热点节点

通过CRC16哈希+16384取模的方式，能保证键在槽位上的均匀分布，而槽位又分配给不同节点，从而实现数据在节点之间的均匀分布，避免“某个节点存储过多数据导致过载”的问题。

5.2 支撑集群水平扩展，降低扩容成本

由于槽位数量固定，新增节点时只需将其他节点的部分槽位迁移到新节点，无需重新计算所有键的映射关系；删除节点时，将其槽位迁移到其他节点即可。整个过程无需停机，实现“在线扩容/缩容”。

5.3 保障集群高可用，配合副本机制容错

Redis集群中每个主节点都可以有一个或多个从节点，从节点会复制主节点负责的所有槽位的数据。当主节点故障时，集群会自动将其从节点升级为主节点，接管所有槽位的服务，实现故障自动切换，而哈希槽的映射关系仅需更新为“新主节点”，不影响数据访问。

六、总结

Redis哈希槽是集群架构的“灵魂”，它通过“固定槽位数量+键-槽-节点的三层映射”，完美解决了数据分布式存储、水平扩展和负载均衡的核心问题。理解哈希槽，不仅要掌握“16384个槽”“CRC16取模”等表层知识点，更要理解其背后“平衡效率与扩展”的设计思想。