记录一下那天晚上的排查过程。Redis Cluster 从六节点扩到九节点，代码里用 mget 一次取十个 key，扩容后三分之一请求报 CROSSSLOT Keys in request don't hash to the same slot。
刚开始盯着「客户端版本太老，不支持重定向跟随」，折腾了半个多小时，排掉了。
原因不止一个，得分开看。批量命令里的 key 没打 hash tag，散落在不同槽。也可能是槽迁移期间客户端路由表还没刷新。
不容易想到的是，key 命名规则不统一，同一个业务分散在多个前缀。
第一件事是确认报错 key 落在哪个槽
redis-cli -c -p 7001 cluster keyslot product:1001随后用 hash tag 把相关 key 收进同一槽
redis-cli -c -p 7001 cluster keyslot '{product:1001}:price'然后把 mget 拆成按槽分组调用
redis-cli -c -p 7001 mget '{product:1001}:price' '{product:1001}:stock'升级客户端并确认集群状态
redis-cli -c -p 7001 cluster info | grep cluster_state这类问题以前遇到过，但这次的触发条件和上次不一样。
改完先别撤，确认这几项。扩容完成后 CROSSSLOT 报错归零，批量读取耗时与扩容前持平，集群状态是 ok 且槽全部覆盖。
补一句。hash tag 只取花括号里的内容做哈希，设计 key 时就把同一个业务对象放进一个 tag，扩容才不会被拆散。这类问题最好一次改到位，反复小改反而容易把原因搅混。