一个商品详情接口，直接查数据库要300毫秒，加了Redis缓存后降到5毫秒——10倍以上的提速，谁不想要？但缓存不是加上就万事大吉，缓存策略选错了，数据不一致、缓存穿透、雪崩这些问题够你喝一壶。

缓存模式怎么选

常用的有三种：Cache-Aside、Write-Through、Write-Behind。API接口开发中最常用的是Cache-Aside，读时先查缓存，没有再查数据库并回写缓存；写时先更新数据库再删缓存。为什么是删而不是更新？因为更新缓存可能有并发冲突——两个写请求同时到达，后更新的反而先写入缓存，数据就脏了。删除操作是幂等的，更安全。

缓存过期时间设置

别图省事所有key都设同一个过期时间，这样会导致同一时刻大量key同时失效，请求全部打到数据库——这就是缓存雪崩。正确做法是在基准过期时间上加随机偏移，比如expire = 3600 + random(0, 300)，让失效时间分散开。对于热点数据，可以设置永不过期，通过后台异步更新来刷新。判断标准很简单：如果某个key的QPS超过整体QPS的10%，就值得做永不过期加异步刷新。

缓存穿透怎么办

恶意请求查询不存在的数据，缓存里没有，数据库里也没有，每次请求都打到数据库。解决方案有两个：一是缓存空值，查询不到也缓存一个null，过期时间设短一点（60秒）；二是用布隆过滤器，在缓存前加一层判断，请求的数据如果布隆过滤器说不存在就直接返回，不用查缓存和数据库。布隆过滤器适合key数量可枚举的场景，比如商品ID范围固定。

缓存命中率监控

加了缓存不等于万事大吉，得盯命中率。通过Redis的INFO stats命令看keyspace_hits和keyspace_misses，命中率低于80%就该排查原因了。常见原因有：过期时间太短、缓存key设计不合理导致大量不重复key、或者缓存被频繁淘汰。用redis-cli --bigkeys找出占用内存大的key，用redis-cli monitor抓一段时间内的key访问模式，对症调整。

缓存用好是利器，用不好是坑。关键是根据业务场景选对策略，持续监控命中率，有问题及时调整。