热点Key问题必须前置分散，依赖本地缓存兜底、Key分片路由和热点自动识别三者协同；用redis-cli --hotkeys需提前配置LFU策略并逐节点执行；product:{id}类Key易因哈希聚集引发热点，应改用模运算打散；本地缓存须加随机过期与互斥锁；动态分片路由风险高，推荐预埋双路径+开关控制；分片后操作需同步作用于所有shard，一致性须压测验证。
直接说结论：热点 Key 问题不能靠“事后补救”解决，必须在写入和访问两个环节做前置分散——本地缓存兜底 + Key 分片路由 + 热点自动识别三者缺一不可。
怎么用 --hotkeys 快速定位真实热点
Redis 4.0.3+ 内置的 redis-cli --hotkeys 是最轻量、最低侵入的探测方式，但它依赖 LFU（Least Frequently Used）计数器，需提前开启配置。如果没开，命令会直接报错或返回空。
-
maxmemory-policy必须设为allkeys-lfu或volatile-lfu，否则--hotkeys不生效 - 执行前确认节点已运行足够时间（至少 5–10 分钟），LFU 计数需要积累周期
- 输出中的百分比（如
[45.45%]）表示该 Key 占当前节点总访问量的比例，比绝对 QPS 更能反映倾斜程度 - 注意它只扫描当前节点，集群环境下需逐个连接主节点执行，不能一键扫全集群
为什么 product:{id} 这种 Key 模式天生容易热
业务常用 product:10086 这类结构，看似合理，但 CRC16 哈希后所有 product: 开头的 Key 都落在相近槽位，尤其当 ID 是连续数字时，product:10086、product:10087 极可能被分到同一节点——这不是巧合，是哈希函数对连续输入的天然聚集效应。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 强制用哈希标签（如
product:{10086}）反而更危险：它把所有相关 Key 锁死在同一槽，专为热点设计 - 真正有效的做法是打散：改用
product:10086:shard{Math.abs(id.hashCode()) % 16}或product:10086:{id % 100} - 模运算比随机后缀更可控，避免因随机导致合并逻辑复杂化（比如库存扣减需遍历所有 shard）
- 注意：分片数别盲目设大，16 或 32 足够覆盖多数场景；超过 64 可能带来合并开销反超收益
本地缓存不是加个 Caffeine 就完事
本地缓存能缓解 Redis 压力，但若只做简单封装，极易引发数据不一致或雪崩——比如过期时间设成 1 秒，恰逢热点 Key 失效瞬间，所有机器同时回源 Redis，等于把压力从一个节点转移到全部客户端再压向 Redis。
- 过期时间必须带随机扰动：
expireAfterWrite(1, TimeUnit.SECONDS)改为expireAfterWrite(1 + ThreadLocalRandom.current().nextInt(500), TimeUnit.MILLISECONDS) - 加载函数里要加互斥锁（如
CacheLoader中用synchronized或分布式锁），防止缓存击穿时大量线程穿透 - 关键点：本地缓存失效后，不能直接调
redis.get(key)，而应走统一的getWithFallback()方法，里面包含降级逻辑（如返回兜底静态值） - 别忘了清理机制：Caffeine 的
maximumSize要结合内存预算设上限，否则 OOM 风险比 Redis 崩溃更隐蔽
动态分片路由的坑比想象中多
很多方案建议“检测到热点后自动切分”，听起来智能，但实际落地时，路由逻辑一旦出错，会导致数据读取错乱或写入丢失——比如旧 Key 还在被读，新分片已开始写，中间没有原子切换。
- 不要在运行时动态改 Key 结构，而是预埋两套路径：
product:10086（默认）和product:10086:shard*（热点启用），通过开关控制 - 分片键必须稳定：用
id % N比用用户 ID 哈希更可靠，后者若用户 ID 生成规则变更，分片结果就不可逆 - 合并读取成本要量化：10 个 shard 并行 get 比单次 get 多出约 2–3ms 网络开销，QPS 超 5k 时这个延迟会明显抬升 P99
- 最易忽略的一点：分片后，
DEL、EXPIRE等操作必须同步作用于所有 shard，漏掉任何一个，就会残留脏数据
真正卡住人的从来不是方案本身，而是分片后的数据一致性校验、本地缓存与 Redis 的双写时序、以及热点识别阈值的动态调整——这些没法靠配置开关解决，得在每次上线前用真实流量压测验证。
