Redis Cluster 核心原理：哈希槽与数据路由实战

在 Redis 的高可用架构中分片集群Sharding Cluster解决了单机内存和性能瓶颈。不同于主从哨兵模式分片集群引入了“哈希槽”的概念实现了数据的去中心化存储。今天我们就来彻底搞懂 Redis 集群是如何通过哈希槽来分配数据以及如何利用这一机制优化我们的业务存储。哈希槽集群的“物流分拣系统”Redis 集群并没有采用一致性哈希而是引入了哈希槽的概念。这是一个非常精妙的设计我们可以把它想象成一个拥有 16384 个格口的物流分拣中心。有同学可能要问为什么是16384我特意去搜了下这是个最佳实践大小4kb总量固定Redis 集群预定义了 16384 个哈希槽编号从 0 到 16383。节点映射集群中的每个 Master 节点会负责一部分槽位。例如一个 3 主 3 从的集群槽位分配可能如下节点 7001负责 0 - 5460节点 7002负责 5461 - 10922节点 7003负责 10923 - 16383数据并不是直接绑定在某个节点上而是绑定在槽位上。这种设计让集群的扩容和缩容变得异常简单——只需要移动槽位即可无需全量迁移数据。数据路由你的数据去哪了当我们执行SET key value时Redis 是如何知道该把数据存在哪台机器上的呢这依赖于一个三步走的计算流程。第一步确定“有效部分”Redis 首先会检查 Key 中是否包含大括号{}。无大括号整个 Key 就是有效部分。例如num的有效部分就是num。有大括号只有大括号{}内部的内容才是有效部分。例如{itcast}num的有效部分是itcast。第二步计算哈希值利用 CRC16 算法对“有效部分”进行计算得到一个哈希值。第三步取模定位将哈希值对 16384 取余得到的余数就是该 Key 所属的槽位编号。计算公式SLOTCRC16(key) 16383实战演练控制数据存储位置理解了原理我们来看看在实际操作中会发生什么。假设我们连接到了 7001 节点使用redis-cli -c -p 7001注意-c参数开启了智能路由这个一定不要省略。场景一普通存储当我们执行SET num 123时有效部分是num。计算CRC16(num) % 16384结果为 2765。2765 在 0-5460 范围内属于 7001 节点。结果数据直接存储在 7001。场景二触发重定向当我们执行SET a 1时有效部分是a。计算CRC16(a) % 16384结果为 15495。15495 在 10923-16383 范围内属于 7003 节点。结果7001 节点发现该槽位不归自己管会返回一个MOVED错误告诉客户端“去 7003 节点找”。客户端收到后会自动跳转。场景三利用哈希标签如果我们执行SET {a}number 1有效部分变成了{}中的a。计算结果依然是 15495因为有效部分还是a。结果数据被路由到 7003 节点。进阶技巧哈希标签的商业价值你可能会问为什么要设计{}这种机制难道就是为了把数据存到别的节点吗当然不是。哈希标签是解决“跨槽操作”难题的钥匙。在 Redis 集群中涉及多个 Key 的操作如MGET、MSET或 事务要求所有 Key 必须在同一个槽位上否则会报错。应用场景商品分类存储假设我们要存储用户 1001 的姓名、年龄和城市。为了保证事务的一致性我们需要它们存储在同一个节点上。SET {user:1001}:name AliceSET {user:1001}:age 25SET {user:1001}:city Beijing通过将{user:1001}作为哈希标签Redis 在计算槽位时只会计算user:1001的哈希值。因此这三个 Key 会落入同一个槽位也就必然在同一个节点上。知识小结核心考点速查表为了方便大家复习我将本文的重点整理成了下表知识点核心内容技术实现应用场景哈希槽16384 个槽位分配到集群节点CRC16 算法计算 key 的哈希值并取模数据存储位置判定、数据分片插槽分配7001: 0-54607002: 5461-109227003: 10923-16383集群初始化时自动分配实现数据分片存储Key 路由机制根据有效部分计算插槽值1. 带{}时取括号内内容2. 无{}时取整个 keySET number 123→ 2765 插槽SET {a}number 1→ 15495 插槽自动重定向到正确节点数据绑定原理数据与插槽绑定而非节点节点故障时插槽转移保证数据可定位性哈希标签控制 key 的有效部分SET {mobile}1001SET {mobile}1002商品分类存储、批量查询优化操作命令演示插槽计算 → 重定向节点 → 现象说明SET number 123(7001)SET a 1(7003, MOVED)SET {a}number 1(7003)验证有效部分变为大括号内容总结集群通过 16384 个槽位实现数据分片。数据路由依赖于CRC16算法和% 16384取模。利用{}哈希标签我们可以强制将相关联的数据“捆绑”在同一个节点从而支持批量操作和事务这是生产环境优化的关键技巧。