缓存与异步消息

7.1缓存读写模式：四种摆位

缓存的本质是把一份数据的副本放在离请求更近、读取更快的地方。第 01 章的延迟阶梯给了它存在的理由：内存读取约 100ns、同机房一次 RTT 约 0.5ms、缓存命中比一次回源数据库调用快约三个数量级。差距越大，缓存的杠杆越大。但缓存是数据的第二份拷贝——按本教程主线那把尺子说，凡是复制状态就要付一致性的账：源数据一变，缓存里的旧值就成了谎言。四种模式的差别，正是这笔账记在谁头上、什么时候记。

cache-aside（旁路缓存）

应用代码直接编排缓存与数据库，缓存库自己不碰数据库。读：先查缓存，命中就返回；未命中（cache miss）就回源数据库、把结果写回缓存、再返回。写：更新数据库，然后删除缓存里对应的键（不是更新它）。这是最常见的模式，Redis + 关系库的组合默认就是它。

它真正的难点藏在"读未命中回填"和"写后删"是两条独立、各自非原子的序列里。设想一个慢读：线程 A 读 miss，从数据库取到旧值 v1，正准备写回缓存，此刻被调度器挂起；线程 B 完成一次写，把数据库更新成 v2 并删掉缓存（此刻缓存是空的，正确）；然后 A 醒来，把手里早已过期的 v1 写进缓存。结果缓存里稳定地躺着 v1，而数据库是 v2——这个错值会一直存在，直到 TTL 到期或下一次写再次删它。这就是 cache-aside 的不一致窗口：它来自两条非原子序列的交错，不是"网络抖动"。

read-through / write-through（读穿 / 写穿）

把缓存与数据库的 I/O 编排下沉到缓存层自己（如本地 Caffeine + CacheLoader，或带 loader 的缓存服务），应用只跟缓存对话。read-through：miss 时缓存自己去加载数据库并回填，应用感知不到回源。write-through：写时缓存同步地把值写进自己和数据库，两者都成功才返回。好处是一致性比 cache-aside 强（写时缓存与库同步刷新，不靠"删后回填"）、应用代码更干净；代价是每一次写都要付一次数据库写延迟——它把缓存的"加速读"优势让出一部分去买写一致性，因此适合读远多于写的场景。

write-behind（写回 / write-back）

写命中缓存就立即返回，缓存把脏数据先攒在内存里，由后台线程批量、异步地刷回数据库。这是四种里写延迟最低的——写操作完全不等数据库。代价也最重：缓存节点在刷盘前崩溃，那些"已经向客户端确认成功"的写就真的丢了。这与 第 04 章异步复制的失效模式同构：返回得越早，崩溃窗口里丢的就是已确认数据。要让 write-behind 不丢，必须给它配 WAL（write-ahead log，预写日志，先把变更落到顺序日志再异步应用）——这正是数据库自己用来兼顾"快"和"不丢"的老办法。

7.2缓存的三种崩法：穿透 / 击穿 / 雪崩

这三个中文术语在社区里固定下来、含义彼此独立，混用是排障时的常见错误。它们的区别不在"现象都是数据库被打爆"，而在触发条件不同——所以修复手段也完全不同，没有一招通杀。

穿透（cache penetration）：查一个根本不存在的键

请求的键既不在缓存、也不在数据库。cache-aside 的回填逻辑只在数据库查到结果时才写缓存，于是这类"查不到"的请求每次都 miss、每次都打到数据库——缓存形同虚设。攻击者用海量随机不存在的 ID 刷接口，就是冲着这条路来的。修复有两条：① 把"不存在"这个结果本身也缓存起来（缓存空值，配一个较短的 TTL，避免占满内存）；② 布隆过滤器（Bloom filter，一种概率型集合，能在 O(1) 内回答"一定不存在"或"可能存在"），把所有合法键预先放进去，请求先问它，答"一定不存在"就直接拒绝、连数据库都不碰。

击穿（hotspot invalidation）：单个热键瞬间过期

某个极热的单键（如明星主页、爆款商品）TTL 到期的那一瞬间，成百上千个并发请求同时 miss、同时回源重建同一份数据——数据库在一刹那被同一个键的重复查询砸穿。这与穿透的根本区别是：击穿的键在数据库里是存在的，问题出在"过期瞬间的并发回源"，而非"查不到"。修复：① 互斥重建（singleflight，让同一键的并发回源只放一个请求去重建、其余等待结果），把 N 次回源压成 1 次；② 逻辑过期——值永不真正从缓存删除，而是携带一个逻辑过期时间戳，读到"逻辑已过期"时由后台异步刷新、前台先返回旧值，用一点陈旧换"永不击穿"。

雪崩（cache avalanche）：大批键同时失效或缓存层整体宕

两种成因：① 大量键被设置了相同的 TTL（比如启动时批量预热），到点同时过期，瞬间把所有读压力一起推给数据库；② 缓存节点/集群整体宕机，所有读直接穿到数据库。它与击穿的区别是"规模"——击穿是一个热键，雪崩是成片的键或整层。修复：① 给 TTL 加随机抖动（如基础 TTL ± 一个随机量），把过期时刻打散、避免同时到点；② 缓存层做高可用（多副本、主从），别让整层成为单一故障域；③ 配熔断/降级，缓存挂了就限流保护数据库，而不是让它被流量冲垮（熔断与降级的完整机制在 第 08 章）。

7.3缓存与数据库一致性：只能做到"尽量"

一个被反复追问的问题：缓存和数据库怎么保证强一致？诚实的回答是——做不到，只能 best-effort。原因回到 第 05 章：缓存和数据库是两个独立的存储系统，跨两个系统的写无法原子完成（这正是 第 06 章双写问题的同一面）。一旦接受这一点，"一致性方案"就都退化成"把不一致窗口压到多小、多快自愈"。

延迟双删：面试常考，但不是正确性保证

流程是：先删缓存 → 更新数据库 → 睡几百毫秒 → 再删一次缓存。第二次删是为了清掉"第一次删之后、数据库更新生效之前"被并发读回填进来的旧值。问题在那个"睡几百毫秒"：睡多久才够，取决于从库复制延迟、慢查询、GC 暂停等无法预知的量。睡短了清不干净，睡长了白白增加写延迟，且无论睡多久，总存在边缘情况让旧值在第二次删之后才被回填。

binlog 驱动失效：现代生产更倾向的做法

与其让应用代码同步地协调"删缓存 + 写库"（双写，天然有原子性漏洞），不如让缓存失效由数据库的变更日志单向驱动：订阅 MySQL 的 binlog（Canal、Debezium 这类 CDC 工具，CDC = change data capture，变更数据捕获），数据库一旦提交变更，就由订阅方去删/更新对应缓存。它的优势是：失效事件的源头就是数据库已提交的事实，不再依赖应用代码记得删、也不怕应用删缓存时崩在半路；缓存失效从"双写的一侧"变成了"对已提交事实的单向投影"。代价是引入一条 CDC 链路（多一个组件、有自己的延迟和投递语义）——而这条链路的投递语义，正是下一节要讲的 at-least-once，所以消费端删缓存的动作必须幂等（删本来就幂等，天然契合）。

7.4投递语义：为什么 exactly-once 是神话

从缓存切到异步消息。消息系统给出三种"听起来"的投递语义，但只有两种是真正的基石：

• at-most-once（至多一次）：发出去就不管、不重试。可能丢，但绝不重复。适合能容忍丢失的数据（如可降采样的指标、日志）。
• at-least-once（至少一次）：重试直到收到 ack（acknowledgement，确认回执）。绝不丢，但可能重复。是绝大多数业务消息的默认选择。
• "exactly-once（恰好一次）"：每条消息不丢不重——在传输层这是不可能的。

为什么不可能？这是"两将军问题"的直接后果。发送方发出消息后在等 ack，结果 ack 一直没回来。此刻发送方无法区分两种情形：是消息根本没送达（该重发），还是消息送达了、但回来的 ack 在网络里丢了（重发就会重复）。两种情形在发送方看来完全一样，而它必须做出选择：要么不重发（接受可能丢——退回 at-most-once），要么重发（接受可能重——退回 at-least-once）。没有第三条路。所以传输层的真实选项永远只有"可能丢"和"可能重"两种，"恰好一次"在传输层不存在。

那 Kafka 宣传的 exactly-once 是怎么回事？它是真的，但有严格边界：Kafka 的 exactly-once 只在 Kafka 内部成立——"读一个 topic、处理、写另一个 topic 并提交 offset"这一串若全在 Kafka 事务里，能做到对 Kafka 自己恰好一次。可一旦处理过程里有外部副作用（调用一次 RPC、往关系库写一行、发一封邮件），那个副作用就不在 Kafka 的事务边界内，Kafka 管不了它的重复。所以只要消费逻辑触碰外部系统，就仍然必须自己实现幂等键——Kafka 的事务不是"端到端 exactly-once"的免罪符。

7.5幂等消费与背压：把重复和过载都吸收掉

幂等消费：去重表必须和副作用同事务

幂等（idempotent，同一操作执行一次和执行多次，对系统状态的影响相同）是 effectively-once 的落脚点。给每条消息一个全局唯一的幂等键（业务上的订单号、或生产端生成的消息 ID），消费端处理前先查去重表：见过这个键就跳过，没见过才执行并记录该键。这套话术里藏着一个最容易被忽略、却最致命的细节——

Kafka 自 3.0 起默认开启的幂等生产者解决的是另一段路：它用 PID（producer ID，生产者 ID）加每个分区的递增序列号，让 broker 能识别并丢弃"因网络重试而重发的同一条消息"，避免生产侧重发导致的重复写入 broker。但它管的只是生产者到 broker 这一跳的重发去重——消费者的重复处理和外部副作用，它一概管不了。这两段去重职责必须分清，否则又会陷入"以为 Kafka 帮我兜底了"的错觉。

背压：跟不上时向上游说"慢点"，而不是无界缓冲

背压（backpressure，下游处理不过来时主动向上游施加的反向压力）回答的是一个生死问题：消费者的处理速度跟不上生产速度时怎么办。错误答案是把积压的消息无界地缓冲在内存里——队列只会越堆越长，最终 OOM（out of memory，内存耗尽）让消费者崩溃，问题没解决还多了一次宕机。正确答案是让消费者把"我跟不上"这个信号传回上游，迫使上游放慢或暂停发送。

不同 broker 实现背压的机制不同：Kafka 是 pull 模型——消费者主动按自己的节奏拉取，拉得慢了上游自然就压着没人取，背压是天然的、不需要额外信令。RabbitMQ 是 push 模型——broker 主动把消息推给消费者，所以要靠 prefetch（预取上限，限制 broker 向单个消费者"在途未 ack"的消息数）来卡住推送速度，叠加 TCP 流控做底层兜底。理解这点能解释一个常见困惑：为什么 Kafka 很少听到"消费者被推爆"，而 RabbitMQ 不设 prefetch 就容易把慢消费者冲垮。

7.6日志型 vs 队列型 broker

消息中间件分成两个谱系，差别不在"快慢"，而在消息读完之后还在不在、以及消费进度由谁记。这一个设计选择，决定了它们各自擅长和不擅长什么。

队列型（RabbitMQ 为代表）：ack 即删，broker 记账

消息被消费者 ack 之后就从队列里删除，broker 逐条跟踪每条消息投递给了谁、是否已确认。这是"聪明的 broker + 简单的消费者"模型：路由（exchange/binding）、重试、死信、延迟投递这些复杂逻辑都由 broker 承担，消费者只管收和 ack。它擅长任务分发型场景（一个任务被某一个 worker 处理掉就行），灵活的路由是它的强项。代价：消息一旦被消费就没了，无法重放；broker 要为每条消息记账，海量堆积时压力大。

日志型（Kafka 为代表）：append-only，消费者记 offset

消息以 append-only（只追加）的方式写进分区日志，按时间或大小保留（比如保留 7 天），消费完不删除。消费进度不由 broker 记，而是每个消费者组自己记一个 offset（偏移量，标记"我读到日志的哪个位置了"）。这是"简单的 broker + 聪明的消费者"模型，带来两个队列型给不了的能力：① 多个消费者组各记各的 offset，能独立、互不干扰地重放同一份日志（一组做实时计算、另一组重跑历史，互不影响）；② broker 不为每条消息记投递状态，吞吐极高。

代价同样清晰：顺序和并行度被分区数钉死——Kafka 只在单个分区内保证顺序，消费并行度上限就是分区数；而且同一分区内，一条处理很慢的消息会阻塞它后面所有消息（head-of-line blocking，队头阻塞），因为 offset 是按顺序推进的，绕不过去。所以"一个慢 key 拖慢整条分区"是 Kafka 的固有失效模式，不是配置问题。