Redis集群通过CRC16算法对key（或其Hash Tag）哈希后对16384取模确定Slot编号（0–16383）；仅依赖key字符串本身，支持{}提取Hash Tag，且必须使用ITU-T X.25标准CRC16实现。
Redis集群怎么确定一个Key落在哪个Slot上
Redis集群用CRC16算法对key做哈希，再对16384取模，结果就是它所属的Slot编号（0–16383）。这个过程不看value、不看命令类型、也不受客户端驱动影响——只取决于key字符串本身。
注意：如果key含大括号（如"user:{1001}:profile"），Redis会提取最内层{}之间的内容作为哈希输入，也就是只对"1001"算CRC16。这是为支持Hash Tag，让相关key落到同一节点。
- 没大括号 → 对整个
key字符串计算CRC16("mykey") % 16384 - 有大括号 → 只取第一个
{}内的子串，如CRC16("1001") % 16384 - 多个
{}或嵌套？只认第一个合法闭合对，其余忽略
CRC16实现不一致会导致Slot错位吗
会，而且很隐蔽。Redis服务端用的是ITU-T X.25标准的CRC16（初始值0xFFFF，多项式0x1021，低位先入），不是常见的Modbus或ZIP变种。如果你在客户端自己实现哈希逻辑，或者用第三方库硬编码了别的CRC16，算出来的Slot就和Redis实际分配的对不上。
典型现象：客户端认为"order:123"该发往Node A，但Redis集群返回MOVED重定向到Node B；或者使用redis-cli --cluster check时报告slot分布不一致。
- 别手写CRC16——优先调用Redis客户端内置的
keySlot()方法（如Jedis的ClusterCommand.getSlot(key)、node-redis的Cluster.getSlot(key)） - Python用
redis-py时，RedisCluster.keyslot("mykey")已封装正确逻辑 - 若必须手动算，确认CRC16函数参数：poly=0x1021, init=0xFFFF, xorout=0x0000, refin=True, refout=True
为什么是16384而不是65536或其它数
16384（即2¹⁴）是权衡结果：足够分散负载，又控制心跳包开销。每个节点需在Gossip消息中广播自己负责的slots位图，16384 bit ≈ 2KB，而65536 bit就要8KB——集群规模大时，这直接影响通信效率和收敛速度。
另外，Redis官方明确不支持运行时调整slot总数，16384是硬编码在源码里的常量（REDIS_CLUSTER_SLOTS），改它等于fork一个私有版本。
- 不能通过配置增大或减小slot数量
- 扩容/缩容靠迁移slot，不是新增slot空间
- 单个slot只能由一个主节点负责，但可有多个从节点
遇到MOVED/ASK重定向说明什么
MOVED表示请求的key当前归属另一个节点，且该映射关系已稳定（比如完成了一次slot迁移）；ASK则表示slot正在迁移中，本次请求临时去目标节点查，但后续仍应发给源节点——直到收到下一次MOVED。
这两类响应不是错误，而是集群正常协作机制。客户端必须解析响应内容里的ip:port并跳转，否则会持续失败。
-
MOVED 1234 10.0.1.5:6379→ 更新本地slot 1234的路由缓存，下次直连 -
ASK 1234 10.0.1.5:6379→ 本次请求加ASKING指令后重发，不更新缓存 - 某些老客户端（如早期Lettuce）未正确处理
ASK，导致迁移期间读写失败
真正容易被忽略的是：哈希结果依赖key字面量，而非序列化后的二进制。比如用JSON序列化对象当key，字段顺序、空格、换行稍有不同，CRC16就完全不同——这种差异在线上环境极难排查。
