缓存不是加了就完事
很多人觉得，网站一慢就上缓存，Redis 一装，问题解决。可真到大促、秒杀这种场景，你会发现缓存本身也可能成为瓶颈。比如你做个商品详情页，每秒几万次请求打进来，哪怕缓存命中率99%，那1%的穿透也足以压垮数据库。
真正的高并发场景下，缓存不只是“存数据”，得讲究策略和结构。
分层缓存：别把鸡蛋放一个篮子
单一缓存层在极端情况下容易雪崩。推荐本地缓存 + 分布式缓存组合使用。比如用 Caffeine 做 JVM 内缓存，扛住大部分读请求，再用 Redis 做共享层兜底。
Cache<String, Object> localCache = Caffeine.newBuilder()
.maximumSize(1000)
.expireAfterWrite(5, TimeUnit.MINUTES)
.build();这样即使 Redis 出现网络波动，本地还有缓冲，不至于直接击穿到数据库。
缓存穿透：恶意查询怎么办
有人故意查不存在的商品ID，每次都不命中，请求直奔数据库。解决方案很简单：对查无结果的 key 也缓存空值，设置短过期时间，比如30秒。
String value = redis.get(key);
if (value == null) {
// 查询数据库
String dbValue = queryFromDB(key);
if (dbValue == null) {
// 缓存空值，防止穿透
redis.setex(key, 30, "");
} else {
redis.setex(key, 300, dbValue);
}
}缓存雪崩：别让缓存集体下班
大量 key 同时过期，瞬间请求全涌向数据库。解决办法是给过期时间加个随机偏移量，比如原本设5分钟，改成 5分钟 ± 1分钟。
另外可以提前预热热点数据，在高峰期前主动加载进缓存，避免冷启动。
热点 key：小心被挤爆
某个明星突然上热搜，相关页面访问量暴增，一个 key 被反复读取，可能压垮单台 Redis 实例。这时候可以对热点 key 进行分片，比如加个后缀变成 key_1、key_2，再做负载均衡。
或者启用 Redis 集群模式，让请求分散到多个节点。监控也要跟上，及时发现异常访问模式。
写操作怎么处理
很多人只关注读缓存，写的时候直接删缓存。但高并发下多个写请求同时触发，可能引发缓存击穿。建议采用“先更新数据库，再删除缓存”的策略，并用消息队列异步化处理，减少响应时间。
// 更新数据库
updateDB(data);
// 发送删除缓存消息
mq.send("delete_cache", key);这样即使删除失败，也能通过重试机制补救，保证最终一致性。