Java 排障专题

做缓存一致性设计时，团队最后几乎总会绕到三个方案上：

很多缓存事故，真正开始失控，不是在 Redis 已经完全不可用的时候，而是在它只是先抖了一下的时候。

有一类缓存事故特别容易把人带偏：监控大盘上的命中率看着不难看，甚至还能稳在 95% 以上，可数据库回源就是降不下来，接口 RT 也始终贴着高位。

缓存预热这件事，最容易把人带进一个很危险的误区： 任务成功了，就默认读链已经稳了。

TTL 这个词很容易被说轻。很多系统最初都是先给个 5 分钟、10 分钟、30 分钟，跑起来再说。可真到事故现场，TTL 从来不只是“缓存活多久”的小参数，它决定的是： 流量会不会在同一时间窗里重新砸回数据库。

很多人对熔断有一个很自然的想象：

这类问题我第一次遇到时，现场特别有迷惑性。

线上一旦出现 CPU 持续高位 ，同时 Young GC / Full GC 也开始明显抖动 ，团队很容易很快分成两派：有人盯着 GC 图怀疑 JVM 顶不住了，有人盯着热点线程认定是业务代码先出问题。