Redis注解到底怎么用才牛逼，才能让它发挥最大威力呢？

第一，别把@Cacheable只当成“省事工具”，要把它当成“战略武器”。

很多人用@Cacheable，想法很简单：这个方法慢，给它加个缓存，这没错，但格局小了，牛逼的用法是，你在设计业务的时候，就思考“哪些数据是适合被战略缓存的？”。

你做的是一个电商首页,首页的商品分类列表、轮播图数据，这些数据可能一天才变一两次，如果你只是在查询数据库的那个Service方法上草草加个@Cacheable，那只是解决了“有无”问题，真正牛逼的做法是：

1. 主动预热：在项目启动时，或者通过一个管理后台的按钮，主动调用一次这个方法，让热点数据在用户访问前就已经安安稳稳地躺在Redis里了，这时候@Cacheable的用处是，后续所有请求根本不会打到数据库上。
2. 设置超时时间（TTL）要有策略：别随便设个30分钟了事，对于几乎不变的数据，可以设置很长的时间，比如12小时甚至24小时，然后通过后面要讲的@CacheEvict来手动清除，对于变化相对频繁的，可以设置一个随机值，比如基础是10分钟，加上一个随机0-2分钟的偏移，这样可以避免缓存同一时间大量失效，导致“缓存雪崩”。
3. Key的生成要讲究：默认的Key生成策略可能很臃肿，最好用key属性自定义一个清晰明了的Key，比如category:list:all，这样以后你在Redis桌面管理器上查看时，一目了然，也便于维护。

（参考来源：实际高并发项目中的缓存设计经验）

第二，@CacheEvict和@CachePut是保证数据一致性的“左右护法”，要用得精准。

缓存最大的难题是数据更新后,如何让缓存失效或更新，乱用@CacheEvict会导致脏读，不用则会导致用户看到过期数据。

• 精准打击：@CacheEvict的key一定要和@Cacheable的key对应上，你更新了ID为1的用户信息，那么失效的Key就应该是user:info:1，更牛逼一点，如果你有一个查询所有用户列表的缓存user:list:all，在增删改用户时，最好也把这个列表缓存失效掉，因为数据已经变了。
• allEntries的慎用：@CacheEvict有个allEntries属性，设置为true会清空整个命名空间（比如所有以user:开头的Key），这玩意威力巨大，但破坏性也极强，除非你非常确定需要清理整个区域（比如一种业务逻辑导致所有相关缓存都不可用了），否则不要轻易使用，随便用它会误伤大量无辜的热点缓存，可能瞬间拖垮数据库。
• @CachePut的用武之地：当你需要每次都必须执行方法，并用结果更新缓存时，就用它，更新用户积分后，我们希望最新的积分信息立刻进入缓存，那么就在更新方法上使用@CachePut，并确保key和查询方法的一致，这样，后续的查询就能直接拿到最新值。

（参考来源：Spring官方文档中对缓存注解的语义解释及实践中的教训）

第三，高级玩法：用@Caching和自定义注解应对复杂场景。

业务不可能总是简单的增删改查,用户下单成功后，你需要同时：

1. 清空用户的购物车缓存（@CacheEvict(key = "'cart:' + #userId")）。
2. 更新用户的订单列表缓存（@CachePut(key = "'order:list:' + #userId")）。
3. 可能还要更新商品库存的缓存。

这时候,你难道在方法上堆砌好几个注解吗？太不优雅了，牛逼的玩法是使用@Caching注解，把它和多个@CacheEvict、@CachePut组合起来，更更进一步，你可以自定义一个注解，比如叫@CacheOrderComplete，把@Caching的逻辑封装进去，这样，业务代码上只需要一个简洁的自定义注解，意图清晰，可复用性极高。

第四，别忘了“缓存穿透”和“缓存击穿”的防御。

注解本身不解决这些问题,但你的用法必须考虑到，这才是体现功力的地方。

• 应对缓存穿透（查不存在的数据）：可以在查询数据库发现为空时，也在缓存里设置一个短时间的空值（比如30秒），虽然Spring注解没有直接支持，但你可以通过环绕通知（AOP）或者在实际Service方法中自己实现这个逻辑。
• 应对缓存击穿（热点Key突然失效）：对于那种热点Key，比如明星出轨的新闻，缓存失效瞬间可能会有巨大并发去重建缓存，你可以用分布式锁（比如Redis自己实现的SETNX）在注解的AOP外层加一层控制，保证只有一个线程去查询数据库，其他线程等待，虽然这超出了注解本身的功能，但你的架构设计里必须包含这部分。

第五，监控和治理是持续发挥威力的保障。

你搞了一大堆缓存,怎么知道它们命中率怎么样？有没有大量的内存浪费在了不常用的Key上？光靠注解不行，你需要：

1. 接入监控：通过Redis的INFO命令或者监控工具，查看Key的数量、内存占用、命中率等指标。
2. 规范Key的命名：这又说回第一点了，统一的、清晰的命名规范，是后续做监控和自动化治理的基础。

想让Redis注解真正牛逼,就要跳出“技术实现”的层面，上升到“业务架构”和“数据策略”的高度，你要像一个指挥官一样，知道在什么地方（哪些数据）、什么时候（TTL策略）、用什么武器（哪个注解）部署缓存，并且还要有后勤保障（监控和治理），当你把这些都做到了，Redis注解就不再是简简单单的几行代码，而是你保证系统高性能、高可用的核心利器。