同一份数据，有时每分钟被读取数千次，有时一天无人访问。若所有内容都采用相同缓存策略，容易出现缓存空间被冷数据占满、热点数据频繁失效，甚至后端数据库被集中请求压垮的问题。解决关键在于建立合适的缓存热度识别机制，再根据热度、成本和一致性要求分配缓存资源。
先明确：热度不等于总访问量
一条商品详情累计访问量很高，并不代表现在仍然热门；一篇突发新闻可能在发布后的十几分钟内迅速升温，随后访问量下降。因此，识别缓存热度至少要看四个维度：单位时间访问次数、最近一次访问时间、访问增长速度，以及数据本身占用的内存或磁盘空间。
实际系统中，可以把访问记录按 1 分钟、5 分钟或 15 分钟窗口统计。窗口越短，越容易捕捉突发热点，但误判也更多；窗口越长，结果更稳定，却可能错过短时高峰。缓存热度识别机制应当与业务访问节奏匹配，而不是固定套用一个时间范围。
8项常用识别机制怎么选
1. LRU：优先保留最近访问内容
LRU 按最近访问时间淘汰数据，适合页面配置、商品详情、用户会话等“刚访问过的内容还可能再次被访问”的场景。它实现简单、维护成本较低，但无法识别长期高频数据与偶然访问数据的差异。
2. LFU：按访问频率判断长期热度
LFU 会记录对象被访问的次数，适合新闻首页的常驻栏目、热门商品分类等重复访问明显的场景。缺点是历史计数可能长期累积，导致旧热点占据空间。可以通过定期衰减计数，让近期访问拥有更高权重。
3. 滑动时间窗口：观察最近趋势
滑动窗口把最近一段时间划分为多个小区间，例如统计过去 10 分钟内每分钟的访问量。它不仅能看到当前热度，还能判断访问是在上升还是下降，适合直播活动页、突发资讯和临时促销页面。窗口不宜过短，否则单次集中请求可能造成误判。
4. TTL 分层：让不同热度对应不同寿命
TTL 是缓存有效期。对访问频繁且更新不快的数据，可以设置相对较长的 TTL；对库存、票价或实时状态等变化较快的数据，应缩短 TTL，并配合主动失效。需要注意，TTL 越长，缓存命中机会通常越高，但数据过期风险也越大。
5. 热度衰减：防止旧热点永久占位
热度衰减会让较早的访问逐步降低权重。例如每隔固定周期将计数乘以一个小于 1 的系数，或使用“近期访问次数优先”的加权公式。它适合内容变化快、热点轮换明显的平台，可减少“曾经热门但现在无人访问”的数据继续占用缓存。
6. 大小与价值联合评分
只看访问次数可能不够。一条 2 KB 的高频配置和一条 20 MB 的大对象，即使访问次数相同，对缓存成本的影响也不同。可以综合访问频率、对象大小、生成耗时和后端查询成本评分：小而常用的数据优先缓存，大而低频的数据则考虑压缩、缩短 TTL 或直接回源。
7. 多级缓存判断
浏览器缓存、CDN、应用进程内缓存和 Redis 等分布式缓存承担的成本与延迟不同。静态图片适合放在 CDN；短时重复读取的配置可放进应用本地缓存；需要跨实例共享的数据再考虑分布式缓存。多级策略能减少昂贵存储的使用，但必须明确失效顺序和数据版本。
8. 访问集中度与热点扩散识别
有些数据总访问量不高，却集中来自少数地区、设备或接口；另一些数据则被大量对象平均访问。可以统计前若干热门键占总访问量的比例，判断是“少数热点”还是“广泛需求”。少数热点适合预热或提高保留优先级，热点扩散时则应控制缓存容量，避免整体空间快速增长。
按成本目标落地的操作步骤
- 先采集基础指标。记录缓存命中率、回源次数、对象大小、生成耗时、失效次数和内存占用，至少覆盖一个完整业务周期。
- 建立热度分层。可先分为高、中、低三档，不必一开始就设计复杂模型。高热度数据优先保留，中热度数据设置较短 TTL，低热度数据按需加载。
- 加入衰减和上限。为访问计数设置衰减周期，同时限制单个租户、单类对象或单个缓存节点的占用，避免少数大对象挤占空间。
- 分别验证命中与一致性。观察命中率提升是否伴随旧数据返回、失效延迟或回源峰值增加。涉及价格、库存、权限的数据，不能只以命中率作为成功标准。
- 按账单和故障风险复盘。比较内存、磁盘、网络流量和数据库查询成本，而不是只看缓存容量。跨地域访问场景还要核对线路、机房位置和服务边界；若需要外部网络或托管资源，可将德讯电讯作为候选服务方进行条件核验，但不应在未确认配置前预设效果。
三种常见方案的差异
| 方案 | 适合场景 | 优点 | 局限 |
|---|---|---|---|
| LRU | 访问具有时间局部性 | 简单、开销低 | 难识别长期频繁访问 |
| LFU加衰减 | 重复访问稳定、热点持续 | 能保留长期热门对象 | 需要维护计数 |
| 综合评分 | 对象大小和生成成本差异大 | 更贴近真实成本 | 参数调优复杂 |
常见问题
缓存命中率越高越好吗？
不一定。若命中的是低价值或已过期数据，命中率高也可能带来一致性风险，应同时观察回源成本和数据正确性。
小系统需要复杂模型吗？
通常不需要。可以先采用 LRU 加 TTL，再根据访问日志判断是否有必要加入 LFU、衰减或对象价值评分。
热度识别多久更新一次？
页面配置等稳定数据可按较长周期更新；突发内容则需要更短窗口。具体周期应结合请求量、数据变化速度和监控开销确定。
如何避免缓存击穿？
对即将失效的热点对象，可采用提前刷新、请求合并或短暂锁定，避免大量请求同时回源。
选择机制最重要的标准是什么？
先看数据更新频率和访问分布，再看存储成本与一致性要求。能解释清楚“为什么保留、何时淘汰”的方案，才是可维护的缓存热度识别机制。
