当前位置：首页 > 问答 > 正文

Redis注解怎么不缓存才快点，避免无用数据占内存的那些事儿

行,那咱们就直接聊 Redis 注解怎么用才能不拖慢系统，别让那些没用的数据把内存给占满了，这事儿听起来简单，但实际用的时候，很多团队都栽过跟头，关键就一句话：别瞎缓存，要缓就缓那些真正值得缓的。

最直接的一招：干脆别用缓存

听起来像废话,但这是最容易被忽略的，很多人觉得用了 Redis 高性能”了，于是不管三七二十一，所有查询都给它加上 @Cacheable 注解，这就好比为了喝杯水，专门修了一条水管，没必要。

什么时候绝对不该用缓存？

实时性要求极高的数据：比如用户的余额、库存数量，这类数据必须时刻准确，你缓存个几秒钟都可能出大问题（比如超卖），这时候，宁可慢点直接查数据库，也不能用缓存，解决方案就是别加那个缓存注解，让它每次都去查库。
访问频率低到可怜的数据：比如某个配置表，一天也就后台修改时查一两次，这种数据你缓存起来，可能好几天都没人碰一次，纯粹是占着内存不干活，判断标准可以粗略点：如果一个数据一天被访问的次数一只手数得过来，那它就没什么缓存价值。
写多读少的数据：如果一个数据被频繁修改，但很少被读取，那你每次辛辛苦苦把它放进缓存，没多久就又被更新了，缓存命中率极低，缓存频繁被无效化（@CacheEvict）和重新写入的操作本身也有开销，可能比直接读数据库还慢。

（参考来源：美团技术团队关于缓存使用的分享中提到，滥用缓存是导致系统复杂度提升和资源浪费的常见原因）

如果非得缓存，怎么让“无用数据”尽快滚蛋？

有时候一个数据你说不准要不要缓存,或者它确实有价值，但生命周期很短，我们的目标就是让这些数据在完成使命后，麻利地离开内存。

给缓存设个合理的“保质期”（TTL）
- 这是最基本也是最重要的手段,通过 @Cacheable 的 expire 或 timeToLive 参数（具体看你的缓存框架，Spring Cache）给每个缓存设置不同的过期时间。
- 诀窍在于“差异化”：不要所有缓存都设置成一样的 30 分钟，根据数据特性来：
  - 用户会话（Token）：可以设置长一点，7天。
  - 热点新闻文章：可能只需要 10 分钟，因为新闻的热度衰减很快。
  - 数据库里几乎不变的基础数据（如城市列表）：可以设置非常长，甚至不设置过期时间，然后在后台有更新时，手动触发清理（@CacheEvict）。
- 一个常见的错误是 TTL 设得太长，比如把用户昵称缓存 1 小时，结果用户改了昵称，1小时内看到的还是旧的，体验很差，这时候要么调短 TTL，要么在用户修改时主动清除缓存。
用大小限制来兜底
- 有些缓存框架支持给整个缓存池或某个命名空间（CacheName）设置最大容量（size）或内存上限，当缓存数量或总大小快达到上限时，会自动淘汰掉一些不常用的数据（LRU 算法）。
- 这招是个很好的安全网,即使你某些地方的 TTL 没设置好，或者突然来了无法预料的热点数据，它也能防止 Redis 内存被彻底打满，导致服务崩溃，这就好比给水池加了个溢流口，水多了自己会流走。

（参考来源：Redis 官方文档中关于内存管理和淘汰策略（maxmemory-policy）的说明，推荐使用 allkeys-lru 或 volatile-lru 策略作为通用方案）

更精细的控制：手动管理缓存生命周期

@Cacheable 的自动缓存虽然方便，但有时候显得“太笨”，我们需要更精细的操控。

及时清理过时数据（@CacheEvict）
- 当后端数据发生修改时，一定要记得同时把对应的缓存清理掉，比如更新了用户信息，除了写数据库，还要加上 @CacheEvict 注解，确保下次读取时拿到的是最新数据并重新缓存。
- 避免脏数据：这是保证缓存数据一致性的核心，如果只更新数据库不清理缓存，用户读到的就是脏数据。
有选择地更新缓存（@CachePut）
- 这个注解的意思是：不管缓存里有没有，都执行方法，并把方法返回的结果刷新到缓存中，它通常用在写操作上。
- 有一个特别复杂的计算结果,你知道每次更新数据后都需要最新的缓存，那么可以在更新方法上使用 @CachePut，这样在更新完成的同时，最新的结果已经躺进缓存了，下一个读请求直接命中，又快又准。

别忘了，缓存本身也可能成为瓶颈

有时候慢,不是因为你没缓存，而是缓存用错了方式。

缓存穿透：频繁查询一个根本不存在的数据（比如不存在的用户ID），每次都会穿过缓存打到数据库上，解决方案是：即使查不到数据，也在缓存里存一个空值（null）并设置一个很短的过期时间（比如30秒），这样后续短时间内的相同请求就不会再去查库了。
缓存雪崩：大量缓存在同一时刻集体过期，导致所有请求瞬间涌向数据库，数据库扛不住就挂了，解决方案是：给缓存的过期时间加一个随机值（比如基础时间 + 随机几分钟），让它们错开失效。

想让 Redis 注解不拖后腿，核心思想是 “精打细算”。