HGETALL或频繁HGET会卡住整个slot，因Redis按key名哈希固定分配slot，单个hash所有字段共用同一slot，高频访问导致该节点CPU和带宽打满；应改用HMGET、HSCAN分批或拆分为多key分散slot。
为什么HGETALL或HGET频繁访问某个hash字段会卡住整个slot？
Redis的hash结构底层是压缩列表（ziplist）或哈希表（hashtable），但无论哪种，单个hash key始终落在**同一个slot**里——它由整个key名决定，不看字段名。所以哪怕你只读user:{1001}:profile里的nickname字段，整个hash仍被锁在slot 2345上。当这个hash被高频读写（比如每秒几千次HGET user:{1001}:profile nickname），该slot所在节点的CPU和网络带宽就会打满，而其他slot完全空闲。
别用HGETALL查热点字段，改用HMGET + 字段预筛
很多业务习惯先HGETALL再用代码过滤字段，这等于把整个hash从内存拖到网络再丢弃90%数据。对热点hash来说，这是灾难性的带宽浪费和序列化开销。
- 只读固定字段时，直接
HMGET user:{1001}:profile nickname avatar updated_at，避免传输冗余字段 - 字段名有规律（如
ext_*），且数量可控，可提前在应用层维护白名单，禁止动态拼接HGETALL - 若必须遍历，改用
HSCAN+COUNT 100分批，但注意：HSCAN仍走同一slot，仅缓解单次阻塞，不解决根本倾斜
把热点字段拆成独立string key并做slot分散
真正治本的方法是打破“一个hash全绑死在同一个slot”的约束。核心思路：让高频访问的字段拥有自己的key名，并通过高基数tag控制其slot分布。
- 原结构：
user:{1001}:profile（含nickname、avatar等20个字段） - 改造后：
user:{1001 % 8}:nickname:{1001}、user:{1001 % 8}:avatar:{1001}，其中1001 % 8生成0~7共8个tag，把原来挤在1个slot的请求打散到最多8个slot - 注意：不要用
{1001}直接取模，要确保模数足够大（建议≥16），否则仍可能扎堆；更稳妥的是用hash(1001) % N（如MurmurHash3） - 双写过渡期：新逻辑写拆分key，读逻辑先查拆分key，未命中再回源
hash，避免数据断层
客户端缓存+本地LRU绕过Redis单点压力
如果字段内容变更不频繁（如用户昵称一天改不到一次），最省资源的方式是把读请求挡在Redis之前。
- 在应用层加一层本地缓存（如Caffeine），key为
user_nickname_{uid}，TTL设为比Redis中实际过期时间多5秒，防击穿 - 更新时走双删：先删本地缓存，再更新Redis拆分key，最后异步刷新本地缓存（避免更新期间短暂不一致）
- 慎用Redis 6.0+的
CLIENT TRACKING：它依赖连接状态和广播机制，在集群+分片下易失效，且增加proxy负担，不如本地缓存可控
最难的不是算出哪个字段该拆、怎么取模，而是所有调用方（包括定时任务、后台管理接口、离线脚本）都得同步切换key路径——漏掉一个，那个角落里的Lua脚本就会在凌晨三点突然把整个slot拖垮。
