缓存到底下沉到哪一层：应用层 Redis 缓存 vs DB 层（只读副本 + 查询缓存），高并发系统你们的分水岭在哪？

【背景】 我在一家做电商后端的公司待了十几年，见过同一个「读多写少」接口，三个团队三种做法，最后各自踩坑：

• A 组：核心商品详情走本地缓存（Caffeine，TTL 10s + 变更消息失效），P99 稳定在 8ms，但去年一次商品中心发版，变更消息丢了 200ms，导致用户看到旧价下单，赔了钱，最后被迫加「价格字段强校验」兜底；
• B 组：订单列表直接压在 MySQL 只读副本上，靠 buffer pool 命中 + 覆盖索引撑住 2000 QPS，架构最简，但一次大事务把副本延迟拉到 40s，用户投诉「刚下的订单查不到」；
• C 组：全链路 Redis 缓存，P99 最低，但缓存与库的双写一致性、雪崩预案、Redis 集群运维，吃掉了这个小组 40% 的人力。

三组都没错，也都被自己的选择反噬过。所以我想把这个问题摊开聊：同一个读多写少的查询链路，缓存/加速手段到底应该放在哪一层？分水岭到底由什么决定？

【常见分歧】 我大致看到三种立场：

1. 「能下沉就下沉」派：DB 层 buffer pool 本身就是缓存，只读副本 + 覆盖索引 + 合理 SQL，能省掉一整套缓存基础设施；缓存是「给架构偷懒买的保险」。
2. 「应用层优先」派：DB 层延迟方差大（锁、主从延迟、大事务抖动），应用层缓存延迟可控、可观测性好（miss/hit、TTL 都自己掌握），且能跨多语言/多存储统一抽象。
3. 「分层都有」派：热数据本地缓存（Caffeine）挡第一波，中间层 Redis 挡第二波，DB 兜底——但承认这是「用复杂度换确定性」，只在真扛不住时才值得。

我的倾向（先亮观点，欢迎打脸）：分水岭不在 QPS，也不在数据量，而在「这条链路上你能容忍多大的延迟方差和一致性窗口」。具体说：

• 延迟方差敏感（交易、支付、搜索排序）→ 应用层缓存，因为 DB 层的 P99 你控制不了（一次 DML、一次 checkpoint、一次副本追赶都能击穿）；
• 一致性敏感且变更可广播（配置、字典、权限）→ 本地缓存 + 失效事件，TTL 短到业务可接受；
• 两者都不敏感、读模式稳定（报表、历史明细）→ 就压 DB，别加缓存，运维成本是真实成本。 另外我坚持一条：任何「写后读」路径都不该依赖缓存的自动失效，要么走旁路直读，要么写路径显式失效并带重试——这是 A 组赔钱的根因。

【想听大家】

1. 你的系统里「从 DB 直读切到应用层缓存」的触发条件是什么？是 P99 阈值、QPS 水位，还是某次事故倒逼？
2. 本地缓存（Caffeine/自研）vs 分布式缓存（Redis），你们的选型依据——我猜多数人会答「Redis 方便」，但真扛过故障的团队应该有更细的考量？
3. 缓存失效事件丢失（消息乱序/丢失/重复）你们怎么兜底？TTL 兜底、版本号、还是双写校验？
4. 有没有人经历过「缓存层被证明是负资产」——即去掉 Redis 后延迟反而更稳、人力省下的案例？我很想听一个。