hash槽分布不均源于key设计缺陷，因redis集群仅对{}内字符串计算crc16，导致低基数tag（如{1001}、{202404}）使大量key扎堆同一slot；解决需重构key结构，将高基数字段置入{}并取模分片，配合双写过渡与客户端映射刷新。

Hash槽分布不均不是配置问题，而是Key设计问题；直接调节点槽数量或重启集群无法解决，必须从Key结构入手。

为什么crc16(key) % 16384算出来槽位会扎堆？

Redis集群只对{}内字符串做CRC16计算——这是绝大多数倾斜的根源。比如user:{1001}:profile和order:{202404}:list，实际参与哈希的只是1001和202404这两个低基数字符串，导致成千上万个Key挤进同一个slot。

• 常见高危模式：cache:{global}、log:{error}、order:{YYYYMM}
• 危险信号：用redis-cli -c cluster countkeysinslot {slot_id}发现某slot键数超平均值5倍以上
• 注意：redis-cli --bigkeys完全无法暴露这类问题，它只找大Key，不看分布

如何安全改写Key结构避免Tag陷阱？

不能简单删掉{}，否则业务逻辑可能失效（比如Lua脚本里硬编码了{uid}提取）。关键是把高基数字段放进花括号，并控制其取值范围。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 用户类Key：把user:{uid}:orders改成user:{uid % 16}:orders:{uid}，16个子tag分散到不同slot
• 订单类Key：用订单号哈希后取模替代月粒度Tag，例如order:{hash(order_id) % 64}:202404{seq}
• 全局缓存：放弃cache:{global}，改用cache:{shard_id}:config，shard_id来自配置版本号哈希
• 双写过渡：新逻辑写新Key，读逻辑先查新Key，未命中再查旧Key，灰度期结束后下线旧路径

改完Key后为什么数据还是打不到新节点？

客户端SDK（如JedisCluster、Lettuce）会缓存slot-node映射表，Key规则变了但本地映射没刷新，请求仍按旧路由发出去——这是最常被忽略的环节。

• 验证方式：在客户端执行CLUSTER SLOTS命令，比对返回的槽范围是否与新Key计算出的slot一致
• JedisCluster需调用refreshCluster()或设置refreshTriggerRate自动刷新
• Lettuce建议启用ClusterTopologyRefreshOptions并开启adaptiveRefreshTriggersEnabled
• 预发环境务必用真实流量镜像跑一遍，统计新Key生成的slot分布直方图，确认无明显峰谷

真正难的不是算出哪个slot该归谁，而是让所有服务、脚本、监控、告警都同步理解新Key语义——一个没改到位的Lua脚本或定时任务，就能让刚压下去的倾斜重新爆发。