14个血泪场景复盘：Spring Boot分布式缓存的致命陷阱与高可用架构设计缓存最容易给团队制造一种危险错觉: 命中率高了，系统就稳了。真正把服务打垮的，往往不是“没上 Redis”，而是上线后才发现缓存和数据库、缓存和流量、缓存和故障恢复之间，根本不是一个简单的 Key-Value 问题。某电商业务在一次大促中，核心交易链路峰值 QPS 从日常的 4 万一路拉到接近 15 万。系统栈并不寒酸: Spring Boot、Redis 集群、MySQL 主从、消息队列、Kubernetes 都配齐了。可事故依然发生了，而且非常典型。00:03商品详情接口 P99 延迟从 80ms 抬到 1.8s，Redis 热点分片 CPU 顶满。00:08部分热点 Key 恰好过期，大量请求回源，数据库连接池开始耗尽。00:14库存服务出现并发回写覆盖，缓存和数据库短暂不一致，超卖告警触发。00:21Redis 主节点抖动，哨兵切换期间客户端重试放大，应用线程堆积。00:33运维紧急清理缓存试图止血，结果把数据库彻底推到了崩溃边缘。01:10应用侧开始限流降级，非核心接口静态兜底，数据库压力才逐步回落。这篇文章不是“14 个缓存概念速览”，而是把线上最常见、也最容易被低估的 14 个场景串成一条完整链路: 为什么会发生，什么规模下会发生，常见修法为什么不够，Spring Boot 落地时到底该怎么做。先说结论: 缓存架构不是加一个 Redis 就结束分布式缓存这件事，至少同时在处理 4 个问题:读流量削峰，让数据库不用承受每一次查询。写路径解耦，让数据库变更不会立刻扩散成全链路抖动。局部故障隔离，让 Redis 故障不会直接变成数据库故障。数据时效权衡，让业务明确接受“多旧的数据、错多久、由谁兜底”。如果系统里只有“查不到就查库，查到了就回写”，那它最多叫缓存接入，还谈不上缓存架构。一个更接近生产的链路通常长这样: