应用迁移到Redis Cluster后，单个GET和SET都正常，MGET、MSET、事务或Lua脚本却返回 CROSSSLOT Keys in request don't hash to the same slot。这表示一次操作涉及的多个Key被分配到了不同哈希槽，Redis Cluster无法在单个节点上按原有语义执行。
CROSSSLOT不是网络故障，也不是节点数量不足，而是Key分布与命令语义发生了冲突。 正确处理要从数据模型、客户端能力和一致性要求入手，不能靠重试解决。
先确认实例确实启用了Cluster
连接应用实际使用的端点检查：
redis-cli -h REDIS_HOST -p 6379 INFO cluster
redis-cli -h REDIS_HOST -p 6379 CLUSTER INFO关注 cluster_enabled 和集群状态。托管Redis可能通过代理暴露集群能力，命令权限与开源版本不完全一致，应以当前产品文档和客户端模式为准。
如果应用连的是单机Redis，却出现类似跨分片限制，要继续检查代理、中间件或服务端兼容层。必须从真实业务端点确认部署形态，不能只登录某个节点判断。
找出是哪条多Key命令触发错误
常见触发点包括MGET、MSET、SUNION、SINTER、ZUNION、RENAME、带多个Key的Lua脚本，以及MULTI/EXEC中的跨Key组合。
从应用日志保留命令类型、Key模式、客户端版本和错误时间。不要记录完整敏感Key值，可以保留业务前缀与脱敏ID。Redis MONITOR会输出大量命令并增加负载，不应在生产高峰长时间开启。
先定位具体命令和Key集合，才能判断应该同槽、拆分还是改用其他数据结构。
用CLUSTER KEYSLOT验证Key落点
Redis提供命令计算Key对应的哈希槽：
redis-cli -c CLUSTER KEYSLOT user:1001:profile
redis-cli -c CLUSTER KEYSLOT user:1001:orders两个返回值不同，说明它们不能直接参与要求单槽的多Key操作。再测试计划中的hash tag：
redis-cli -c CLUSTER KEYSLOT user:{1001}:profile
redis-cli -c CLUSTER KEYSLOT user:{1001}:ordersRedis官方文档说明，Key里存在有效的 {...} 片段时，只对花括号中的内容计算slot。hash tag必须在Key创建前设计好，它不是给现有Key临时加一个显示标签。
什么情况下适合使用hash tag
同一用户、订单或租户的少量相关Key需要原子事务、Lua脚本或多Key读取时，可以让它们共享业务标识：
user:{1001}:profile
user:{1001}:settings
user:{1001}:quota这些Key会进入同一slot，可以执行受支持的多Key操作。tag应选稳定、基数足够大的标识，避免大量无关数据集中到少数slot。
不要把所有Key都写成 {global}:...。让全业务落在一个slot会失去Cluster分片意义，并制造热点、容量倾斜和单节点瓶颈。
不需要原子性时可以拆分请求
只是想批量读取多个互不相关的Key，并不要求同一时刻快照一致，可以由支持Cluster的客户端按slot分组发送，再在应用层合并结果。
部分客户端会自动scatter/gather，部分客户端则直接返回CROSSSLOT。检查所用语言驱动的Cluster模式、pipeline行为和错误处理，不要假设所有库都能自动拆分。
拆分后要明确失败语义。某一组成功、另一组超时时，应用是返回部分结果、重试失败分组，还是整体失败，需要业务层定义。
拆分能解决吞吐和分布问题，但不会保留原来跨Key命令的原子性。
事务和Lua脚本必须重新评估
Redis Cluster中的事务或脚本涉及多个Key时，这些Key需要位于同一slot。客户端还应显式传入脚本访问的Key，避免脚本根据运行数据拼出不可预测的Key。
先列出事务中所有WATCH、读取和写入对象，再决定使用共享hash tag，还是把流程拆成带幂等标识的多个步骤。跨分片业务状态可能需要数据库事务、消息队列或应用层补偿，而不是强行塞进一段Lua。
原子范围越大，Key分布越受限制；扩展能力与跨对象原子性之间必须做明确取舍。
现有Key不能靠RENAME直接改名
把 user:1001:profile 改为 user:{1001}:profile 会改变slot。跨slot的RENAME在Cluster中不能按单节点操作完成。
安全迁移流程应包含双写或停写窗口、读取回退、数据复制、校验和旧Key清理。不同数据类型使用的复制方式不同，TTL也必须保留。
迁移前记录：
redis-cli -c TYPE user:1001:profile
redis-cli -c TTL user:1001:profile
redis-cli -c CLUSTER KEYSLOT user:1001:profile大Key迁移还要评估网络、内存和阻塞风险。不要在生产环境用KEYS扫描全库并一次性搬迁。
避免把ASK和MOVED当成CROSSSLOT
MOVED 表示客户端请求发到了错误节点，需要更新slot映射；ASK 多见于slot迁移过程，需要临时向目标节点请求。它们与CROSSSLOT不是同一类错误。
使用支持Cluster协议的客户端，并开启合理的拓扑刷新和重定向处理。仅仅在redis-cli中加 -c 可以跟随MOVED或ASK，但不会让跨slot多Key操作变成合法。
客户端会重定向不等于客户端能改变命令的slot约束。
检查分片是否出现新的热点
引入hash tag后，抽样统计关键业务标识的slot，并观察各主节点内存、CPU、请求量和慢命令。一个大型租户的全部Key落到同一slot，仍可能压垮单个分片。
设计tag时可按用户、订单或足够细的业务分区，而不是按业务大类。需要跨用户聚合时，考虑异步预计算、二级索引或专用分析存储。
需要验证Key设计时，可以在 萤光云 创建隔离集群环境，也可以通过 LightNode 部署临时节点。使用生成数据和独立ACL，不要复制生产RDB、AOF或真实密码。
上线前做容量与失败测试
准备覆盖最大批量、不同租户、节点重启、slot迁移和部分超时的测试。对每条多Key命令记录Key数量上限、是否同槽、是否要求原子性以及客户端处理方式。
上线采用小流量灰度，监控CROSSSLOT、MOVED、ASK、超时和各节点负载。出现错误时保留Key模式和slot值，方便判断是漏改Key还是客户端走了旧路径。
验收标准不只是CROSSSLOT归零，还包括slot分布均衡、批量耗时可控、失败语义明确，并且旧Key能够安全回收。
常见问题
redis-cli加-c就能解决CROSSSLOT吗？
不能。-c 能跟随节点重定向，但多个Key仍必须符合命令的同槽要求。
给所有Key加同一个hash tag最省事吗？
短期看简单，长期会让数据集中到一个slot，失去分片扩展能力。tag应使用粒度合适且分布均匀的业务标识。
MGET拆成多个GET结果完全一样吗？
值可能相同，但多个GET之间不具备一次多Key操作的原子观察语义，还要处理部分失败和顺序合并。
温馨提示
CROSSSLOT是在提醒你，原来的单机Key设计与分片模型不兼容。先定义原子边界，再选择同槽tag或应用层拆分，并对现有数据做可回退迁移，才是长期稳定的解决方案。
