热点 Key 指单个 key 承受了全系统大部分请求（明星八卦、爆款商品），会把单个 Redis 分片打满甚至打挂，缓存层在它面前失去分片扩容的意义。发现：1）代理层/客户端埋点统计 key 访问频次上报（如京东 hotkey、有赞 TMC 的方案）；2）Redis 4.0+ 的 hotkeys 参数（需 LFU 策略，只能粗看）；3）monitor 采样分析；4）业务侧预知（运营活动预告）提前标记。
处理手段按场景组合：1）本地缓存前置——热 key 在应用进程内存（Caffeine）里缓存几秒，绝大多数请求不再到 Redis，配合短过期 + 变更广播失效；2）Key 拆分/多副本——把 hotKey 复制成 hotKey#1...#N 多份散到不同分片，读随机路由、写时全量更新，把单点读压力摊到 N 个节点；3）读写分离+只读副本扩容；4）极端场景前置到 CDN/边缘。注意区分三个易混概念：热点 key（访问量集中）vs 大 key（value 过大，阻塞单线程，需拆分/压缩/异步删除）vs 缓存击穿（热 key 过期瞬间并发回源，用互斥重建或逻辑过期）。追问方向：本地缓存与 Redis 的一致性权衡（秒级不一致可接受吗）、逻辑过期 + 异步重建与互斥锁重建的对比、热点探测的实时性（滑动窗口统计）与上报开销。
（约 450 字）