redis集群的slot机制即分片本身，所有key通过crc16(key)%16384映射到0–16383槽位，由集群统一分配节点；{}哈希标签可强制多key同槽，cluster keyslot命令直接返回槽号，多key操作必须同槽否则报crossslot错误。
CRC16(key) % 16384 映射到 0–16383 的某个槽，再由集群将槽分配给具体节点。没有例外，也不支持自定义哈希或范围分片。
为什么 key 会落到某个 slot？
客户端不决定路由，只负责计算 slot：对任意 key（如 "user:1001"），Redis 客户端内部调用 CRC16 算法，再对 16384 取模，得到唯一 slot 编号。例如：
key = "user:1001"
slot = CRC16("user:1001") % 16384 → 结果是 12345（具体值取决于 CRC 实现）
这个过程在所有兼容 Redis Cluster 的客户端（如 redis-py、ioredis、lettuce）中自动完成，你无需手动调用 CRC16。
- 注意：
{}包裹的 key 前缀会影响计算，比如"{user}:1001"和"user:1001"会映射到不同 slot —— 这是实现“同前缀 key 落同一节点”的唯一合法手段 - 空 key 或非法字符（如控制字符）会导致计算异常，部分客户端会直接报错
ERR invalid slot - 非 ASCII 字符（如中文 key）在多数客户端中能正常参与 CRC 计算，但需确认客户端是否做了 UTF-8 编码预处理
如何查看某个 key 分配到了哪个节点？
不能靠猜，也不能靠配置文件查——必须走集群协议验证。最直接的方式是使用 redis-cli -c（启用集群模式）执行 CLUSTER KEYSLOT 和 CLUSTER NODES：
redis-cli -c -p 7000 127.0.0.1:7000> CLUSTER KEYSLOT "user:1001" (integer) 12345 127.0.0.1:7000> CLUSTER NODES | grep "12345"
或者更实用的一步到位命令（需替换 key）：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
redis-cli -c -p 7000 --no-auth-warning -e "CLUSTER KEYSLOT \"user:1001\"" | xargs -I{} redis-cli -c -p 7000 --no-auth-warning CLUSTER GETKEYSINSLOT {} 1
-
CLUSTER KEYSLOT返回 slot 编号，不是节点地址 - 如果返回
(error) MOVED 12345 192.168.1.10:7001，说明当前节点不知道该 slot 归属，重定向信息里已含目标地址 - 不要依赖
INFO replication或CONFIG GET查 slot 分配——这些命令不暴露 slot 映射关系
多 key 操作（MGET/MSET）失败的根本原因
MGET key1 key2 key3 报错 CROSSSLOT Keys in request don't hash to the same slot，不是配置问题，是 Slot 机制的硬性限制：所有 key 必须落在同一个 slot，否则无法保证原子性。
- 解决办法只有两个：
— 用{}强制 key 对齐，例如MGET {user}:1001 {user}:1002
— 拆成多次单 key 请求（牺牲性能换确定性） -
pipeline里混入跨 slot 的命令，也会在执行时被拦截，不是发送阶段报错 - 事务（
MULTI/EXEC）同样受此约束，且集群模式下不支持跨 slot 的 WATCH - Lua 脚本也必须满足所有 KEYS 在同一 slot，否则
EVAL直接拒绝执行
扩容时迁移 slot 的真实成本在哪？
执行 redis-cli --cluster reshard 看似只是挪数字，实际触发的是全量 key 拷贝 + 从节点同步 + 客户端重定向缓冲刷新。关键点不在命令本身，而在迁移期间的副作用：
- 迁移过程中，源节点仍响应该 slot 的读请求，但写请求会被重定向到目标节点（即“双写”状态），可能造成短暂不一致
- 每个 slot 平均含数万 key，迁移 1000 个 slot 可能持续数分钟——期间
CLUSTER NODES显示importing/migrating状态，客户端会频繁收到ASK重定向而非MOVED - 迁移未完成时，若源节点宕机，这部分 slot 会进入
fail状态，直到人工介入修复（redis-cli --cluster fix不总能自动恢复） - 不要在高峰期执行
--cluster-replicas类操作——它本质是批量CLUSTER REPLICATE，会引发主从连接风暴
Slot 分配不是静态配置表，而是运行时状态；任何看似“只改元数据”的操作，背后都牵扯 key 数据的实际移动和集群视角的一致性校验。忽略这点，就容易在凌晨三点收到告警说“集群不可写”。
