Redis集群无法根治热点Key问题，因其哈希分片机制使热Key始终落在同一slot和节点，需结合多级缓存、本地缓存一致性控制及合理失效策略协同解决。
根本原因不是Redis本身慢，而是请求全打到同一个物理节点上
Redis集群的哈希槽机制让热Key天然无法分散
Redis Cluster 用 CRC16(key) % 16384 算出 slot，再把 slot 分配到固定节点。像 product:1001:info 这种 key，无论请求量是 100 QPS 还是 5 万 QPS，它永远落在 slot 8273，也永远路由到 node-2。客户端不改逻辑，扩容加节点也没用——新节点根本收不到这个 key 的请求。
- 集群模式下，
redis-cli --cluster check可以看到 slot 分布，但不会告诉你哪个 slot 正在被打爆 - proxy 层（如 Twemproxy、Codis）也无法重路由热 key，它们只做静态分片
- 哪怕开了 Redis 自带的
redis-cli --hotkeys，没配maxmemory-policy volatile-lfu就查不到真实热 key
单线程 + 高频小操作 = CPU 快速触顶
Redis 是单线程处理命令，HGETALL、LRANGE、ZRANGE 这类操作看似简单，但对大 key（比如含 800 字段的 Hash）会触发大量内存遍历和序列化。一个 HGETALL 耗时从 0.2ms 涨到 8ms，QPS 过 3000 就可能吃满单核 CPU。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
top -H -p $(pgrep redis)能看到单个线程 CPU 占用率持续 >90% -
INFO commandstats里cmdstat_hgetall:calls=123456,usec=9876543这种指标突增，就是信号 - 别信“Redis 很快”，当 99% 请求都卡在同一个线程里排队时，平均延迟会指数级上升
Spring Boot 默认配置放大问题
Spring Data Redis 的 LettuceConnectionFactory 默认启用连接池，但 pool 中的连接仍全部指向同一 cluster node。更关键的是：@Cacheable 或手动 redisTemplate.opsForValue().get() 都不会自动加随机后缀、不做本地缓存、也不 fallback 到副本——它就老老实实发命令。
- 没配
spring.redis.lettuce.pool.max-active？默认是 8，高并发下连接争抢加剧排队 - 用了
@Cacheable(key = \"'product:' + #id\")？那product:1001就是纯正热 key，毫无缓冲 - 没开
lettuce: use-nio-eventloop-group: true？NIO 事件循环未复用，连接建立开销更大
真正容易被忽略的点：热 key 过载往往不是突然发生的。它常伴随一次低风险变更——比如商品详情页加了个新字段，导致 HGETALL 返回体变大 3 倍，CPU 耗时翻倍，而监控告警阈值还卡在旧 baseline 上。
