redis集群倾斜八成因{}滥用，因其仅对花括号内内容做crc16哈希，导致低基数tag（如{1001}、{error}）使大量key落入极少数slot；需用countkeysinslot+getkeysinslot定位问题tag，改写时遵循高离散性、双写过渡、客户端一致性原则，并上线前验证slot分布与节点资源收敛性。
Redis集群出现倾斜，八成是{}惹的祸——不是Hash Tag机制本身有问题，而是它被当成“万能括号”滥用，把本该分散的key全塞进同一个slot。
为什么{}会把流量打到同一台节点
Redis集群用crc16(key) % 16384算slot，但只要key里有{}，就只对花括号里的内容做CRC。比如user:{1001}:profile和order:{1001}:items，实际参与哈希的只有1001这个字符串。如果业务里活跃用户ID集中在1–100，那最多只用到100个slot，而集群有16384个slot——等于99%的槽位空转，100个slot却扛着全部读写压力。
常见误用模式：
-
log:{error}：所有错误日志都走error这个tag → 全进一个slot -
cache:{user}：user值只有admin、guest几个 → 最多占3个slot -
order:{202405}:list：当月订单全塞进一个tag → 月初就爆内存
怎么确认是不是{}导致的倾斜
别猜，直接查slot分布。先看哪个slot异常拥挤：
- 用
redis-cli -c -h {host} -p {port} cluster countkeysinslot {slot}扫出键数Top 10的slot - 再用
cluster getkeysinslot {slot} 100拉一批key出来，观察是否都含相同{xxx} - 注意：
redis-cli --bigkeys只能发现大key，对tag倾斜完全无感
如果抽样发现大量key共享{1001}、{common}或{202405}这类低基数tag，基本可以锁定问题源。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
改{}内容时最容易踩的三个坑
不是删掉{}就万事大吉，改完可能业务读不到数据，或聚合逻辑失效：
- 直接用
{uid % 100}代替{uid}：看似分散了，但如果业务代码里硬编码了{1001}去查，新key就永远命中不了 - 用
{MD5(uid)[0:4]}但没在客户端统一计算：PHP和Java对MD5结果大小写/进制处理不一致，导致同个uid生成不同tag - 灰度期间只写新key、不兼容旧key：用户画像类服务往往强依赖历史key，一停旧路径就丢数据
稳妥做法是双写+渐进式切换：新逻辑写user:{uid % 100}:profile:{uid}，读逻辑先查新key，未命中再查user:{uid}:profile，等旧key自然过期后下线。
上线前必须验证的两件事
改完tag别急着推生产，否则可能把问题从“局部热”变成“全局乱”：
- 拿线上真实uid列表，跑一遍新key生成逻辑，用Python快速验证slot分布：
python -c "import crcmod; crc16 = crcmod.predefined.mkCrcFun('crc-16'); print(crc16(b'user:57:user:profile:12345') % 16384)"，统计10万次输出的slot直方图，看是否落在±5%均值范围内 - 在预发集群部署后，别只看
CLUSTER SLOTS，要盯紧INFO stats里的instantaneous_ops_per_sec和used_memory_human，确保各节点数值收敛，而不是“槽位均匀、流量全歪”
真正难的不是改key格式，而是让业务代码接受“同一个用户的数据不再天然聚在一个slot”——这要求你提前梳理清楚哪些操作真需要多key原子性（如MULTI/EXEC），哪些其实只是习惯性加{}。
