spring boot 需自行构建监控+分析+淘汰闭环来识别 redis 热点数据，因@cacheable和redistemplate不感知热度，且redis的allkeys-lru策略被动、无频次感知、无法联动业务规则；应通过actuator埋点采集访问频次、aop+注解标记热点、redis有序集合+衰减因子实现动态识别与预热。
Spring Boot 本身不提供 Redis 热点数据自动发现能力，必须自行构建监控 + 分析 + 淘汰闭环。直接依赖 @Cacheable 或默认 RedisTemplate 无法识别“哪些 key 正在变热”，更不会触发 LRU 驱逐——Redis 的 maxmemory-policy 是服务端行为，与 Spring Boot 应用层的热点感知无关。
如何用 Actuator + 自定义指标暴露 Redis 访问频次
要让热点可被发现，第一步是采集访问行为。Spring Boot Actuator 默认不暴露 key 级访问统计，需手动埋点：
- 所有通过
RedisTemplate或StringRedisTemplate的读操作（如opsForValue().get()、opsForHash().entries()）都应包裹一层计数逻辑，例如用Counter注册到MeterRegistry - 推荐以
redis.key.access.{keyPattern}为 metric name，避免 key 全量上报（如含用户 ID），可用正则归一化：把user:12345→user:{id} - 不要在 controller 层埋点——那里只管业务路由；应在 service 或自封装的
RedisAccessService中统一拦截 - 启用 Actuator 的 prometheus endpoint：
management.endpoints.web.exposure.include=health,metrics,prometheus，再用 Prometheus 抓取
为什么不能只靠 Redis 的 allkeys-lru 策略
Redis 的 maxmemory-policy allkeys-lru 是被动淘汰机制，它只在内存满时才触发，且基于 key 的最后访问时间（last_access_time），不区分访问频次、不感知业务语义。问题在于：
Twitter热点监控与推文生成
下载
每小时自动在推特搜索中国、加密货币、国际热点、美国热点、特朗普等话题的热度信息，提取前十热点，依据 X 平台真实算法权重（开源代码数据）为每个热点生成高曝光推文或线程。用户提及“推特热点”“Twitter热点”“推特搜索”“热点推文”“生成推文”“社交媒体监控”“Twitter监控”等关键词时触发。
- 冷数据若偶尔被访问一次，
last_access_time就会刷新，可能长期霸占内存，挤走高频但最近未访问的热点 - 没有预热能力：新上线服务时，Redis 是空的，首波请求全打库，
allkeys-lru此时完全不生效 - 无法联动业务规则：比如“商品详情页缓存至少保留 2 小时”，而 LRU 可能 5 分钟就淘汰了
- Spring Boot 应用无法从该策略中获取“哪个 key 刚被淘汰”事件，也就没法做日志告警或补偿加载
用 Spring AOP + 自定义注解实现访问热度标记
真正可行的热点识别，得在应用层主动标记 + 聚合。一个轻量方案是结合 AOP 和本地滑动窗口计数器：
- 定义注解
@HotKey(track = "user:profile")，标注在 service 方法上，track值即为待监控的 key 模板 - AOP 切入点捕获方法执行，并解析 SpEL 表达式（如
#userId）生成真实 key，如user:profile:789 - 使用
ConcurrentHashMap<string longadder></string>+ 定时任务（每 10 秒 flush）统计窗口内调用次数，超过阈值（如 100 次/10s）则写入 Redis 的hot_key_zset，score 设为当前时间戳 - 另起一个调度任务（如
@Scheduled(fixedDelay = 30000)），扫描hot_key_zset中 score > 5 分钟前的成员，批量预热进主缓存区（cache:hothash）
示例片段：
@Around("@annotation(hotKey)")
public Object markHotKey(ProceedingJoinPoint pjp, HotKey hotKey) {
String realKey = parseSpel(hotKey.track(), pjp.getArgs());
hotCounter.computeIfAbsent(realKey, k -> new LongAdder()).increment();
return pjp.proceed();
}
容易忽略的三个关键点
实际落地时，最容易卡住的地方不是代码，而是边界设计：
-
hot_key_zset必须设 TTL（如 2 小时），否则长期累积会撑爆内存；但 TTL 太短（如 5 分钟）会导致刚积累的热度被清零 - 本地计数器（
ConcurrentHashMap）不跨 JVM 实例，集群部署时需改用 Redis 的INCR+EXPIRE组合，否则各节点热度无法合并 - “热点”是动态的，昨天热的商品今天可能滞销——淘汰逻辑不能只看历史峰值，要加衰减因子（如每小时 score *= 0.8），否则旧热点永远压不下去
