Redis集群模式分片机制原理及字符串键路由规则咨询

嘿，咱们来拆解下Redis集群的分片逻辑，刚好对应你提到的字符串键（比如data1、data2）和6个分片的场景：

核心：哈希槽（Hash Slot）机制 #

Redis Cluster的分片不是直接按键或节点哈希，而是靠16384个哈希槽作为中间映射层。每个集群节点会负责一部分连续的哈希槽，所有键的分配逻辑都围绕这些槽展开。

普通字符串键的分片流程 #

对于data1、data2这类普通字符串键，分配逻辑分两步：

1. 计算键的CRC16哈希值：Redis会对键的完整字符串执行CRC16算法，得到一个16位的整数结果
2. 映射到哈希槽：把这个CRC16结果对16384取模（CRC16(key) % 16384），得到的数值就是该键对应的哈希槽编号（范围0~16383）

举个实际例子：假设计算data1的CRC16值是4500，4500%16384=4500；如果你的分片1负责的槽范围包含4500，那data1就会被分配到分片1。同理，data2的CRC16取模结果落在分片2的槽范围内，就会被分到分片2。

6个分片的槽分配规则 #

当你搭建6节点的Redis集群时，槽的分配逻辑是这样的：

• 默认均匀分配：集群初始化（比如用redis-cli --cluster create命令创建集群）时，会自动把16384个槽尽量平均分给6个节点。因为16384不能被6整除，所以前4个节点各负责2731个槽，后2个节点各负责2730个槽
• 支持手动调整：如果你有特殊需求（比如某个节点硬件配置更强，想让它负责更多槽），可以用redis-cli --cluster reshard命令手动调整槽的归属，把指定范围的槽从一个节点迁移到另一个

额外：哈希标签的特殊处理 #

如果你的键包含{}格式的哈希标签（比如order{1001}:detail），Redis会只对大括号内部的内容（这里是1001）计算CRC16并映射槽。这样一来，所有带相同哈希标签的键都会落在同一个槽里，适合需要把相关键放在同一个节点的场景（比如要批量操作这些键时）

集群的访问重定向逻辑 #

当客户端访问某个键时，会先自行计算槽号，然后检查当前连接的节点是否负责这个槽：

• 如果是，直接处理请求
• 如果不是，节点会返回MOVED指令，告诉客户端负责该槽的节点地址，客户端会自动重定向到对应节点处理请求

内容的提问来源于stack exchange，提问作者Jamie