去年我们一个商品详情服务接入了RedisQPS从两千涨到了两万团队欢呼雀跃。三个月后一次缓存雪崩数据库被打穿服务瘫痪了四十分钟。复盘时才发现我们把Redis当成了万能药却踩了缓存设计中最致命的三个坑。误区一把Redis当数据库认为缓存永远可靠这是最危险的心态。很多人用上Redis后就把数据库当成“冷备”读请求全部走缓存写请求也只更新缓存等缓存过期再异步落库。结果呢Redis一重启数据全没了或者内存满了触发淘汰冷数据直接蒸发。我见过一个项目用户购物车只存Redis没设持久化也没同步到数据库。某次运维误操作清空了实例所有用户购物车一夜清零投诉电话被打爆。Redis是缓存不是数据源。它随时可能丢数据、被淘汰、重启。正确的做法是数据库永远是数据的最终归属Redis只做加速。写请求必须落库缓存更新采用“先更新数据库再删除缓存”的策略并配合消息队列或binlog做最终一致性的补偿。永远不要假设缓存里的数据一定存在。误区二缓存粒度失控大key和热key拖垮整个实例缓存设计不只是“存进去、取出来”粒度选择直接决定成败。我见过把整个订单列表序列化成一个大key存进Redis一个key几十KB每次读取都要序列化反序列化网络传输慢还容易引发大key问题。更可怕的是热key某个爆款商品详情每秒被访问几万次全部打在一个Redis节点上节点CPU直接飙到100%。大key的解决方式是拆分订单列表只缓存ID列表详情单独缓存或者用Hash结构分字段存储。热key的解决方式是分散给key加随机后缀把请求打散到多个节点或者使用本地缓存Redis多级缓存热点数据在应用层挡住大部分流量。Redis不是银弹单节点能力有限设计时必须考虑数据的分布和访问模式。误区三过期时间随意设雪崩和穿透接踵而至很多人设置缓存过期时间时很随意统一设成30分钟或者干脆不设。统一过期会导致雪崩——同一时刻大量缓存同时失效所有请求涌向数据库数据库瞬间被打穿。不设过期则会导致内存无限增长最终触发淘汰把有用数据也淘汰掉。正确做法是给过期时间加随机值比如基础30分钟再加0到5分钟的随机偏移让缓存分批失效。对于热点数据可以设置逻辑过期异步更新。同时要处理缓存穿透查询一个数据库里也不存在的key每次都会绕过缓存打数据库。解决方案是缓存空值设置较短过期时间或者用布隆过滤器提前拦截。另外别忘了缓存击穿某个热点key突然失效大量请求同时去数据库加载。可以用互斥锁或分布式锁只让一个线程去加载其他线程等待。写在最后Redis是好东西但它不是数据库不是无限内存更不是自动挡。缓存设计的核心是认清数据源、控制粒度、管理过期。别等到缓存雪崩了才想起数据库的好别等到大key阻塞了才后悔当初的偷懒。用对Redis它是加速器用错Redis它就是定时炸弹。