问题意义：突发性，扩容来不及；动态变化，可能明天就不是热点；全节点冗余成本高
方案：
组件一：识别热点
组件二：本地缓存（应用服务器JVM内存）
为什么宣用本地缓存：
1.源头解决
2.快：内存快于网络传输：避免序列化、压缩、传输
3.解决带宽问题：大Key占用大量网络带宽
难点：
1.识别实时性
2.识别的资源效率：本身不能耗费太多CPU、内存、网络资源
3.内存有限
4.数据一致：本地缓存和Redis需要同步
实现：
京东：全局热点情报局
部署集群作为大脑，负责热点识别和指令下发
流程：
1.客户端记录key的访问信息，异步汇总到集群
2.集群统计访问频率，筛选热Key
3.长连接推送到客户端，更新本地缓存
优点：
1.精度高：捕捉全网数据
2.实时性强：全流程500ms（推送）
3.高并发：单台worker 15万
缺点：
1.复杂度高：维护额外集群和协调系统（etcd）、运维成本
2.业务侵入：客户端集成SDK（一系列API）
扩展：适用于对字符串有热度匹配需求的场景
得物：改造 Redis 内核，让 Redis 服务器自身具备热点探测与广播能力
流程：
1.Redis内部LRU队列，统计key/s访问次数
2.次数达到阈值，Redis判定热key
3.原生发布订阅，将热key通过专属channel广播
4.客户端订阅channel，收到广播更新本地缓存
优点：
1.零侵入性
2.实时性强：内部完成，秒级统计粒度
3.资源开销低：仅依赖Redis内部数据结构
缺点：
1.自主研发难度高
2.长期维护：适配官方版本迭代
B站：热点探测逻辑拆分并下沉到每个客户端
流程：
1.客户端通过Heavy Keeper（类似布隆过滤器，数组 + 多哈希 + 计数器衰减，牺牲微小准确度） 算法识别热点
2.识别后直接存入本地缓存
优点：
1.成本低：仅升级客户端SDK，几MB实现统计，本地缓存命中率35
缺点
1.无全局视野，客户端仅感受自己流量；全局热点均匀分布无法达到一台实例阈值，热点判漏
2.微小误差
方案选型：准确性、实时性、一致性、成本权衡
京东：热点准确/实时要求高，能承担运维成本
得物：强大内核研发团队
B站：快速落地、经济实惠
总结：热key 本质------集中式存储和分布式流量不匹配，紧抓流量分流和效率平衡，热点探测识别流量、本地缓存实现分流、技术成本中权衡