14个血泪场景复盘：Spring Boot分布式缓存的致命陷阱与高可用架构设计

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 个问题:

1. 读流量削峰，让数据库不用承受每一次查询。
2. 写路径解耦，让数据库变更不会立刻扩散成全链路抖动。
3. 局部故障隔离，让 Redis 故障不会直接变成数据库故障。
4. 数据时效权衡，让业务明确接受“多旧的数据、错多久、由谁兜底”。

如果系统里只有“查不到就查库，查到了就回写”，那它最多叫缓存接入，还谈不上缓存架构。

一个更接近生产的链路通常长这样: