讲一次你设计的缓存架构，踩过什么坑？

我先用旁路缓存结构讲：读请求先查缓存，未命中回源 DB 并回填；写请求更新 DB 再删缓存。三大经典问题按方案说：穿透用空值缓存或布隆过滤器、击穿用互斥锁或热点不过期、雪崩用过期时间加随机打散和多级缓存。我在实习项目里给热点配置加了本地缓存，QPS 扛住了三倍增长。

我踩过的最深坑是一致性：先更新 DB 后删缓存，删除失败导致脏读很久。改造方案：删除失败进重试队列，关键场景用订阅 binlog 的异步删除替代业务代码里删，业务与缓存解耦。另一次是缓存雪崩——一批 key 同一时刻过期，教训是 TTL 必须加随机抖动，并且容量规划按失效后回源峰值算。

缓存架构我按数据特征分类设计：读多写少做旁路缓存，写多场景先写缓冲合并，热点 key 做多级缓存与分片，大 value 考虑拆分或压缩。一致性上讲清各方案的窗口期：延迟双删、binlog 订阅、版本号，按业务容忍度选。最后是可观测性：命中率、回源 QPS、大 key 慢查询三个核心指标进大盘。

追问『为什么是删缓存不是更新缓存』：并发写时更新缓存可能乱序覆盖，删除让下次读回源，语义简单可靠；『先删缓存再更新 DB 行不行』：不行，删后读请求会把旧值重新填回；『Redis 挂了怎么办』：熔断降级直连 DB 限流保护 + 集群高可用，缓存是加速层不是 correctness 层。