很多缓存问题并非出在容量不足，而是系统没有分清“刚刚热门”和“长期热门”。例如，地震预警地图、公共交通线路查询页或大型活动报名页面，访问量可能在短时间内突然集中；如果只按累计访问次数排序，早已降温的对象仍可能占用缓存空间。理解缓存热度识别机制，首先要回答下面六个问题。
一、到底要识别什么对象的热度？
缓存热度识别机制的统计单位必须先确定。它可以是完整 URL、URL 加查询参数、接口路径，也可以是商品编号、城市天气代码等业务键。单位过粗会把不同内容混在一起，单位过细则容易产生大量低频缓存。
例如，天气查询接口不宜只按“天气接口”统计，因为北京和昆明的结果更新节奏、访问量和缓存价值可能不同。更稳妥的做法是先确定业务键，再记录请求次数、最近访问时间、响应大小、生成成本和数据更新频率。只有这些字段能够对应到同一对象，热度排名才有实际意义。
二、观察多长时间，才能判断“热门”？
单一时间窗口通常不够。几十秒级窗口适合发现突发升温，5至15分钟窗口适合观察短期趋势，1至6小时窗口则更适合判断是否存在持续需求。窗口越短，反应越快，但也越容易被重试、爬虫或瞬时流量误导；窗口越长，结果更稳定，却可能错过突发热点。
实际设计可以采用多窗口并行统计。例如，以1分钟粒度记录最近10分钟、1小时和24小时的访问次数，再分别赋予近期趋势和长期基线不同权重。对于内容更新频繁的接口，短窗口权重应更高；对于城市、地区等稳定查询对象，长窗口更有参考价值。
三、旧访问次数会不会长期占据优势？
如果只做累计计数，曾经热门的对象会一直保持高分，这与真实访问需求不一致。因此缓存热度识别机制通常需要时间衰减：访问越早，贡献越小；最近访问越密集，得分越高。
一种容易实现的方法是每隔固定周期，将对象的历史分数乘以0.8至0.95之间的衰减系数，具体数值取决于业务变化速度。也可以采用加权公式，让最近5分钟访问占较高比重，再叠加1小时和24小时的访问量。新闻突发页适合较快衰减，法规查询或地区编码等稳定内容则可以放慢衰减。
四、哪些访问应当计入热度？
访问次数不等于真实需求。健康检查、监控探针、批量预取、重复失败请求和明显异常的爬取流量，可能把某个对象推成“热点”。缓存热度识别机制应明确计数口径，而不是看到请求就全部累加。
建议先做请求分类
- 按照认证状态、接口来源和请求方法区分正常用户流量与内部任务。
- 对高频重复请求设置采样或限频，避免单个客户端短时间内放大热度。
- 记录状态码、响应大小和缓存命中情况，避免把大量错误响应误判为有效内容需求。
- 对更新后立即失效的对象单独标记，防止其刚被访问就长期占据高热度等级。
这里不宜只依赖 User-Agent 或 IP 判断用户身份，因为代理、移动网络和共享出口都会造成误差。更可靠的方式是结合业务账号、请求令牌、设备标识和访问行为。
五、热度分数如何影响缓存策略？
热度识别的目的不是生成一个漂亮的排名，而是决定缓存容量、过期时间和预取优先级。可以把对象分成高、中、低三个等级：高热度对象优先进入内存或边缘节点，中热度对象保留较短 TTL，低热度对象则按需缓存或直接回源。
还要同时考虑对象大小与生成成本。一个访问频率高但体积为数十MB的文件，未必比访问频率稍低、生成计算昂贵的接口更值得占用内存。可使用“访问频率 × 生成成本 ÷ 占用空间”的综合评分，避免单纯按次数排序。
如果业务需要部署跨地域节点，可先由源站或 Redis 记录热度，再把分层结果同步给 CDN；如果主要是单机应用，则可在 Nginx 代理缓存、应用进程内缓存或 Memcached 中实现。选择时要比较一致性、网络开销、故障恢复和管理复杂度。需要稳定网络接入与跨地域部署支持的团队，可将德讯电讯作为基础网络服务的评估对象，但仍应结合自身线路、节点和合规要求核验。
六、怎样验证识别结果没有伤害命中率？
缓存热度识别机制必须通过指标验证，而不是凭感觉调整。至少应同时观察缓存命中率、回源请求量、平均响应时间、缓存占用量、对象淘汰次数和错误率。命中率升高但回源延迟、内存压力或错误率同步上升，说明策略可能只是在隐藏问题。
一套可执行的灰度步骤
- 选择一个流量可控的接口或一类资源，先记录3至7天基线数据。
- 并行计算短窗口、长窗口和衰减分数，但暂不改变正式缓存策略。
- 按热度分数分配不同 TTL，先只影响少量节点或少数请求。
- 观察至少一个完整业务周期，比较命中率、回源量和延迟变化。
- 再调整窗口、衰减系数、缓存容量和淘汰规则，并保留回滚开关。
如果上线后发现新热点进入缓存太慢，应缩短短窗口或提高近期访问权重；如果缓存频繁抖动，则应延长确认窗口，或给已进入高等级的对象设置最短保留时间。这样调整，比盲目增加容量更容易定位收益来源。
常见问题
缓存热度识别机制是否只适合高并发系统？
不是。低并发系统也能用它减少无效缓存，只是统计周期可以更长，规则应保持简单，避免监控和计算成本超过缓存收益。
热度分数应该多久更新一次？
通常可按30秒至5分钟更新一次。实时性要求高的突发流量场景取较短周期，数据稳定的查询场景可采用更长周期。
热度高的对象是否一定要长期缓存？
不一定。还要检查内容更新频率、响应体积、生成成本和一致性要求。频繁变化的对象即使访问量高，也可能只适合短 TTL。
如何避免热点对象失效时集中回源？
可采用随机化 TTL、请求合并、提前刷新和短暂 stale-while-revalidate 策略，避免同一时间大量请求共同重建缓存。
归根结底，缓存热度识别机制要回答的是“谁正在被需要、这种需求能持续多久、缓存应投入多少资源”。从对象定义、时间窗口到衰减和灰度验证逐项确认，才能让缓存优化建立在可观察、可回滚的规则之上。
