韧性 · XB 现场笔记

缓存集中失效会放大回源工作

Mon, 22 Nov 2027 00:00:00 +0000

缓存雪崩或击穿所造成的一个关键风险，是并发未命中对同一依赖发起大量重复工作。同时到期只是触发条件之一：容量淘汰、刚部署的空缓存、缓存服务不可用，都可能造成类似突发。即使只有一把热门键，也足以压垮后端。判断风险时应数清楚：一份结果尚未计算完的这段时间内，到底有多少次重建真正抵达数据源。

在真实边界内合并工作

Go 的 singleflight Group 对同一键，在这个 Group 内最多保持一次在途函数执行；重复调用者共享结果，也共享错误。不同 Group 之间不会协调，即使它们位于同一个进程；不同服务实例通常也各有自己的 Group。因此它既不是分布式锁，也不是保存已完成结果的缓存。把 Group 放在每个请求内部重新创建，无法实现跨请求合并。

实际使用时，应让请求共享同一个 Group，并使键准确表示等价工作。不同租户、权限、币种或响应表示如果错误地使用同一个键，可能拿到不属于自己的结果。对于缓存回填，在共享函数内部应再次检查缓存，确实仍缺失才访问数据源，并在函数返回前完成成功结果的缓存写入。这些存储操作都不是 singleflight 自动提供的能力。

错开时间不能改变新鲜度承诺

随机抖动可以打散不同条目或独立副本的到期时间，却不能阻止访问同一过期热键的人一起未命中。如果最大 TTL 是业务规定的新鲜度上限，在有界范围内随机缩短寿命，不会偷偷越过这个上限；任意增加正向抖动则改变了原有承诺。不能脱离请求量、计算成本和允许陈旧程度，宣称几个百分点或几秒钟就普遍足够。

提前刷新和允许使用旧响应，有机会避免用户等待，但必须有明确业务语义。暂时展示上一版公开目录可能可接受，已经撤销的权限或当前余额则未必可以。并发合并只减少重复计算，不负责判断陈旧内容能否使用；如果缓存完全是空的，系统仍需要取得一份数据源结果，不能把后台刷新当作无条件的可用性保证。

坏掉的样子

共享加载函数一旦卡住，可能同时拖住很多等待者。要为数据源调用设置执行期限，也让每个调用者能限制自己的等待时间。DoChan 返回的是结果通道，不是取消机制：某个等待者离开，不会自动停止底层执行。Forget 允许同一键重新启动一次执行，但并不取消原有执行，用它解除等待可能重新制造两次并行加载。

错误只在本次执行仍处于在途状态时共享。执行结束后立刻重试，会向故障依赖发起一轮又一轮新请求。应根据依赖的实际约束设置重试与准入策略，对可以缓存的“不存在”和瞬时失败分别处理。另一个常见误判是把进程内的数字推广到全局：一百个各有 Group 的实例，仍可能同时产生一百次重建，本地只执行一次不等于源站只收到一次。

快速验证

需要 Go 1.25 或更新版本；本次使用 Go 1.27.0 和 x/sync v0.22.0。在下面创建的独立模块目录中，将 Go 代码放入 main.go，再运行 go run -race main.go。只有依赖安装需要外网。程序从“已经发生冷缓存未命中”的边界开始，用有计数器的加载函数观察行为，没有连接真实数据库、缓存服务，也没有实现 TTL 定时器。

stampede_lab=$(mktemp -d)
cd "$stampede_lab"
go mod init example.invalid/stampede-lab
go get golang.org/x/sync@v0.22.0

package main

import (
 "errors"
 "fmt"
 "sync"
 "sync/atomic"

 "golang.org/x/sync/singleflight"
)

const callers = 12

func require(ok bool) {
 if !ok {
 panic("unexpected result")
 }
}

func wave(groups []*singleflight.Group, failure error) int32 {
 var calls atomic.Int32
 gate := make(chan struct{})
 results := make([]<-chan singleflight.Result, callers)
 load := func() (any, error) {
 calls.Add(1)
 <-gate
 if failure != nil {
 return nil, failure
 }
 return "catalog-v1", nil
 }
 for i := range results {
 results[i] = groups[i%len(groups)].DoChan("catalog", load)
 }
 close(gate)
 for _, result := range results {
 r := <-result
 require(r.Shared && r.Err == failure)
 if failure == nil {
 require(r.Val == "catalog-v1")
 } else {
 require(r.Val == nil)
 }
 }
 return calls.Load()
}

func main() {
 var plain atomic.Int32
 var workers sync.WaitGroup
 gate := make(chan struct{})
 for range callers {
 workers.Add(1)
 go func() {
 defer workers.Done()
 plain.Add(1)
 <-gate
 }()
 }
 close(gate)
 workers.Wait()
 require(plain.Load() == callers)
 fmt.Println("without coalescing: 12 loader calls")

 group := new(singleflight.Group)
 require(wave([]*singleflight.Group{group}, nil) == 1)
 require(wave([]*singleflight.Group{group}, nil) == 1)
 fmt.Println("one Group: 1 call per wave; completed results are not cached")
 other := new(singleflight.Group)
 require(wave([]*singleflight.Group{group, other}, nil) == 2)
 fmt.Println("two independent Groups: 2 loader calls")

 failure := errors.New("origin unavailable")
 require(wave([]*singleflight.Group{group}, failure) == 1)
 require(wave([]*singleflight.Group{group}, nil) == 1)
 fmt.Println("one error reaches 12 callers; next wave starts a new load")
}

未合并的基线执行十二次加载。所有调用加入同一个 Group 时，每一轮只执行一次；在同一个 Group 上再运行第二轮，仍会新增一次执行，说明完成结果并未被保存。把十二名调用者分给两个独立 Group，就得到两次加载。故障轮次让十二名调用者收到同一个错误，随后成功的轮次仍会重新加载，而不是读取已缓存的错误结果。

实验用通道闸门让共享加载保持在途，直到所有 DoChan 调用完成注册才放行，因此无需靠睡眠长度或碰巧的调度顺序制造重叠。这里同一轮的所有结果都会标记 Shared 为真，包括最初发起者收到的结果。每个结果通道只接收一次即可；DoChan 不会关闭这些通道，如果对它执行 range 并等待结束，程序就会一直等待。

验收真实服务时，应在隔离环境安排冷缓存测试，同时记录加载次数、等待人数、请求延迟和失败数。验证范围需要包括多个实例和数据源超时，不能只看正常运行时漂亮的缓存命中率。这次 race 检查证明的是此程序在观察到的执行中没有报告数据竞争，并不覆盖生产缓存所有交错顺序，更不代表全局容量、超时及恢复策略已经验收。

来源

Go x/sync v0.22.0：singleflight，Group 范围、DoChan、错误共享与 Forget，已核验 2026-09-07。
AWS Builders’ Library：缓存挑战与策略，冷缓存、请求合并、失败行为与基于实测的过期策略，已核验 2026-09-07。

熔断器阻止对故障服务的轰炸

Tue, 06 Apr 2027 00:00:00 +0000

熔断器决定的是一个新的调用，是否还应该到达看起来不健康的依赖。它可以立即拒绝，避免继续为很可能失败的请求投入资源，但不会修复依赖、取消已经运行的调用，也不能证明所有被拒工作本来都会失败。它是否有用，取决于真正实现的失败信号、作用域和恢复政策，而不只是有没有三个状态名称。

明确政策，而不只是画出状态

关闭表示允许调用通过，不代表每次调用都会成功；断开表示按照熔断政策拒绝新调用；半开则允许有限的试探工作，先取得一些恢复证据，再决定是否重新放行普通流量。不能把状态名字直接读成依赖的客观健康证明。

检测规则也不一定是滑动窗口内的失败百分比。Fowler 的示例统计失败，并在成功后重置；其他实现可能使用时间窗口、失败比例、慢调用阈值或最小样本数。应该明确当前使用的规则，而不是借用一张状态图，就默认阈值和统计方法已经确定。

下面的实验按完成顺序统计连续两次已分类失败，使用五秒冷却期，并且只允许一个半开探测。一次成功会把连续失败数清零。这些数字方便验证状态转移，不是生产配置建议；实际门槛需要结合故障形态与业务容忍度决定。

分类失败，并限定影响范围

调用方参数错误，不一定表示依赖已经宕机。需要确定哪些异常、状态码和慢结果应该影响熔断判断。本地直接拒绝的请求，也不同于已经到达依赖后失败的请求；如果把二者混在同一个失败统计里，熔断器可能不断用自己的拒绝强化拒绝状态。

状态应覆盖你真正想保护的故障范围。某个分片或操作不可用，不一定意味着其他独立提供方也应该被阻止。反过来，如果有成千上万个进程各自维护熔断器，每个都允许一个探测，总探测量仍可能很大。“只放一个半开请求”可能只是每实例一个，不是全局一个。

超时仍然不可缺少。一个永远不结束的调用，会占住连接或工作线程，却可能始终不产生足以触发熔断的完成结果。准入决定不能替代截止期限、并发上限和资源清理；等待结果所消耗的资源，也应进入实际验收范围。

恢复是一场受控试探

冷却时间结束后，应原子地占用探测名额。如果多个线程都先看见“现在可以试一下”，然后各自放行，所谓单探测就变成了一批突发请求。实验使用锁保护很短的状态修改，不会在依赖操作实际运行期间一直持有这把锁。

已经在途的旧调用，其结果如何处理也需要明确。这里进入新的断开阶段时会增加本地代次，旧许可对应的结果不能关闭这个较新的断开状态。代次只是模型内部的记账，不是分布式 fencing token，也没有能力撤销已经发生的远程工作。

探测失败会开始另一轮冷却，探测成功则关闭这个实验里的熔断器。但是，一次成功不证明依赖已经能够承接所有返回流量。如果需要逐步恢复，应该验证真实的流量准入政策，而不是认为只要存在“半开”状态，就必然实现了平滑放量。

坏掉的样子

阈值过于激进，会拒绝原本可以成功的请求；冷却过长，又会在依赖恢复后继续阻止调用。范围过大容易掩盖局部健康，而重试循环如果不停捕获断开异常，即使没有继续请求下游，也仍可能浪费本地资源，使故障路径消耗超出预期。

应分别观察转发调用、已分类结果、本地拒绝、状态变化和探测结果。测试持续失败、偶尔成功、并发争抢探测以及迟到的完成消息。一个计数器单测通过，并不证明真实依赖会安全恢复；需要沿着请求、资源占用和实际恢复流量继续检查。

快速验证

保存为 breaker_check.py，用 Python 3.10 以上版本执行 python3 breaker_check.py。实验已在 Python 3.14.4 上运行，只使用标准库。代码模拟结果，并注入表示单调时间的数值，不真实等待，也不访问服务；半开名额则由八个真实线程竞争，检查准入决定是否一起完成。

from concurrent.futures import ThreadPoolExecutor
from threading import Barrier, Lock


class OpenCircuit(Exception):
 pass


class Breaker:
 # Explicit fixture policy: two consecutive classified failures, five-second cooldown.
 def __init__(self):
 self.state, self.failures, self.until = "closed", 0, 0
 self.epoch, self.probe_busy = 0, False
 self.lock = Lock()

 def acquire(self, now):
 with self.lock:
 if self.state == "open":
 if now < self.until:
 raise OpenCircuit
 self.state = "half-open"
 if self.state == "half-open":
 if self.probe_busy:
 raise OpenCircuit
 self.probe_busy = True
 return self.epoch, True
 return self.epoch, False

 def complete(self, permit, succeeded, now):
 epoch, probe = permit
 with self.lock:
 if epoch != self.epoch:
 return # This outcome belongs to an earlier breaker generation.
 if probe:
 self.probe_busy = False
 self.epoch += 1
 self.failures = 0
 self.state = "closed" if succeeded else "open"
 if not succeeded:
 self.until = now + 5
 elif self.state == "closed":
 self.failures = 0 if succeeded else self.failures + 1
 if self.failures >= 2:
 self.state, self.until = "open", now + 5
 self.epoch += 1


breaker = Breaker()
other_dependency = Breaker()
forwarded = []


def invoke(succeeded, now):
 permit = breaker.acquire(now)
 forwarded.append(now) # A modeled dependency invocation, not a network call.
 breaker.complete(permit, succeeded, now)


invoke(False, 0)
assert breaker.failures == 1
invoke(True, 1)
assert breaker.failures == 0
late = breaker.acquire(1)
invoke(False, 2)
invoke(False, 3)
assert breaker.state == "open" and breaker.until == 8
other_permit = other_dependency.acquire(4)
other_dependency.complete(other_permit, True, 4)
assert other_dependency.state == "closed"
before = len(forwarded)
try:
 invoke(True, 7.99)
except OpenCircuit:
 pass
else:
 raise AssertionError("open circuit must reject before dispatch")
assert len(forwarded) == before
breaker.complete(late, True, 7.99)
assert breaker.state == "open"
print("success resets consecutive failures; two later failures open until time 8")
print("open calls are not dispatched; an older in-flight success does not close a newer open generation")

gate = Barrier(8)


def probe_attempt(_):
 gate.wait(timeout=5)
 try:
 return breaker.acquire(8)
 except OpenCircuit:
 return None


with ThreadPoolExecutor(max_workers=8) as pool:
 permits = list(pool.map(probe_attempt, range(8)))
admitted = [permit for permit in permits if permit is not None]
assert len(admitted) == 1 and admitted[0][1] is True
assert breaker.state == "half-open" and breaker.probe_busy
breaker.complete(admitted[0], False, 8)
assert breaker.state == "open" and breaker.until == 13
print("eight simultaneous half-open candidates receive one probe permit and seven refusals")
print("failed probe opens a new cooldown ending at time 13")

try:
 breaker.acquire(12.99)
except OpenCircuit:
 pass
else:
 raise AssertionError("second cooldown must still apply")
probe = breaker.acquire(13)
breaker.complete(probe, True, 13)
assert breaker.state == "closed" and not breaker.probe_busy
invoke(True, 14)
assert other_dependency.state == "closed" and other_dependency.failures == 0
print("a successful later probe closes this breaker; another dependency has separate state")

开始时的一次成功会清零失败数；后面两次失败让熔断器断开到时间八。在这之前发起调用，不会增加模拟下游调用记录。先前获准、后来才完成的成功结果，也不能关闭新一代的断开状态；另一依赖早已存在的熔断器仍然可以使用，没有被一并影响。

到时间八，八个同时到来的候选请求中只有一个获得许可，其余七个被拒绝。这个探测失败后，又开始一轮到时间十三结束的冷却。之后的探测成功，会让当前熔断器关闭，并恢复普通调用准入。断言检查的是这些明确的状态和许可变化。

模型要求每个获准调用都恰好报告一次已经分类的完成结果。真实传输超时、取消、自动错误分类、跨进程探测协调、库集成和恢复吞吐量没有在本例中测试。适合时应复用成熟实现，并依据实际工作负载验证它的精确契约，而不是将这个小模型当作完整生产熔断库。

来源

Martin Fowler：熔断器，失败计数、成功重置与试探恢复，已核验 2026-09-08。
Azure 架构：熔断器，状态语义、异常分类、并发与故障范围，已核验 2026-09-08。
Python 线程工具，并发许可实验使用的锁与同步屏障，已核验 2026-09-08。

陈旧缓存需要有界策略

Mon, 01 Feb 2027 00:00:00 +0000

陈旧响应可以在源站故障时维持公开手册的可读性，也可能保留过时价格、已撤销权限或误导性的状态。可用性并不天然高于正确性。启用这种行为之前，应先确定哪些信息允许继续使用、什么条件下可以复用，以及最多能旧多久，而不是看到一次错误响应就无条件拿旧成功结果代替。

用可用性换新鲜度

过期和淘汰是两件事。过期响应仍可留在缓存里，用于条件验证或受到许可的陈旧响应；但冷缓存或已经淘汰条目的缓存，没有旧正文可返回。陈旧指令无法凭空创造副本，保存着字节也不会自动授予复用权限。选中的响应还必须匹配当前请求，包括相关 Vary 维度和访问边界，不能拿另一个请求留下的成功内容填补故障。

如何表示

stale-while-revalidate 允许在有界窗口内返回旧响应，同时尝试不阻塞该响应的验证。stale-if-error 则允许在尝试访问源站遭遇符合条件的错误时使用旧响应。两者触发条件不同，都不强制缓存保存内容，也不能保证每种缓存实现都支持。请求到达时若已越过允许窗口，不能因为之前有过一次许可，就继续无限期使用旧内容。

对于 max-age=30, stale-if-error=60，额外六十秒从新鲜期结束后开始计算，不是从每一次失败尝试重新开始。候选响应的总年龄窗口约为九十秒。RFC 5861 指定了会形成 500、502、503、504 的错误场景。认证失败或资源不存在，不能随手重新包装成可用性故障，再用旧的成功响应掩盖真正需要客户端看到的结果。

成功的条件验证不一定重新下载正文。三零四响应可以依据验证元数据更新存储响应，同时保留原来的表示字节。应把这种结果与替换正文的二百响应、故障期间的陈旧命中分别记录；三种情况可能显示相同页面，却对应不同的新鲜度依据，不能仅靠正文是否改变判断验证是否发生。

坏掉的样子

每次重验证失败后都把 Age 清零，会把有界例外变成无限陈旧。保留旧正文却刷新存储时间戳，也会造成同类错误。失败时应保留年龄；只有真正的新响应或成功验证，才提供更新新鲜度的依据。后台验证通常由流量触发，所以一个长期无人访问的缓存，不一定会在下一次用户访问之前主动把内容更新好。

只读或幂等并不代表可以安全返回旧内容。一个 GET 也可能涉及对时效敏感的权限或价格。RFC 9111 禁止在适用的 no-cache、must-revalidate 等指令不允许时复用陈旧响应。应避免互相矛盾的策略，并测试实际部署的缓存如何处理这些限制。另外，RFC 5861 中关于旧 Warning 字段的建议，已被废弃该字段的 RFC 9111 更新，不能把它当作当前验收必需项。

观察指标中要区分陈旧响应和新鲜命中，记录总年龄、错误类别以及验证是否成功，同时避免记录秘密信息。如果每次都返回旧内容，漂亮的 HTTP 成功率可能掩盖持续故障的源站。恢复验收必须确认发生了真实替换或成功验证，而不是只看到源站进程重新启动，就宣布数据已经恢复新鲜。

快速验证

准备 Node.js 与 npm。本轮使用 Node 24.19.0 和已有的 http-cache-semantics 4.2.0 安装运行了 JavaScript。安装固定版本后，用 NODE_PATH="$stale_lab/node_modules" node 执行 JavaScript。这是使用虚构响应和受控时钟的确定性策略与正文选择实验，不发送请求，也不制造真实宕机；只有安装阶段需要联网。

stale_lab=$(mktemp -d)
npm install --prefix "$stale_lab" --ignore-scripts --no-audit --no-fund --package-lock=false http-cache-semantics@4.2.0

const assert = require("node:assert/strict");
const CachePolicy = require("http-cache-semantics");

const start = Date.parse("2026-09-07T00:00:00Z");
let clock = start;
class TestPolicy extends CachePolicy {
 now() { return clock; }
}
const request = { url: "https://example.test/manual", method: "GET", headers: {} };
const policy = new TestPolicy(request, { status: 200, headers: {
 "cache-control": "public, max-age=30, stale-if-error=60",
 etag: '"revision-a"', age: "0",
} });
const oldBody = Buffer.from("manual revision A");
clock = start + 35000;
const decision = policy.evaluateRequest(request);
assert.equal(decision.response, undefined);
assert.equal(decision.revalidation.synchronous, true);
assert.equal(decision.revalidation.headers["if-none-match"], '"revision-a"');
console.log("age 35: validate before using stale-if-error");

for (const status of [500, 502, 503, 504]) {
 const result = policy.revalidatedPolicy(request, { status, headers: { "cache-control": "no-store" } });
 assert.equal(result.modified, false);
 assert.equal(result.policy, policy);
 assert.equal(result.policy.responseHeaders().age, "35");
 const body = result.modified ? Buffer.from("origin error") : oldBody;
 assert.equal(body.toString(), "manual revision A");
 console.log(status, "uses old body without resetting Age");
}
const denied = policy.revalidatedPolicy(request, { status: 403, headers: { "cache-control": "no-store" } });
assert.equal(denied.modified, true);
assert.equal(denied.policy.storable(), false);
console.log("403 does not use the stale success response");

clock = start + 89000;
assert.equal(policy.revalidatedPolicy(request, { status: 503, headers: {} }).modified, false);
clock = start + 91000;
const expired = policy.revalidatedPolicy(request, { status: 503, headers: { "cache-control": "no-store" } });
assert.equal(expired.modified, true);
assert.equal(expired.policy.storable(), false);
console.log("age 89: stale allowed; age 91: error must be surfaced");

const recovered = policy.revalidatedPolicy(request, { status: 200, headers: {
 "cache-control": "public, max-age=30, stale-if-error=60",
 etag: '"revision-b"', age: "0",
} });
assert.equal(recovered.modified, true);
assert.equal(recovered.policy.age(), 0);
assert.equal(recovered.policy.satisfiesWithoutRevalidation(request), true);
const newBody = Buffer.from("manual revision B");
const delivered = recovered.modified ? newBody : oldBody;
assert.equal(delivered.toString(), "manual revision B");
console.log("recovery 200: replace the body and start the new policy");

年龄三十五秒时，正常决策要求同步验证；单独的 stale-if-error 不会授权立即把旧响应当作命中返回。随后四种符合条件的虚构错误都保留版本 A 和原策略，向下游返回的 Age 仍然是三十五秒，而不是被重置成零。403 分支不会复用旧成功正文，并且这条带 no-store 的错误响应不具备存储资格。

同一个旧条目在八十九秒年龄时仍可覆盖符合条件的错误，在九十一秒时则不行，重复失败没有延长窗口。之后收到带版本 B 的成功 200，会产生新鲜策略并选择新正文。实验同时检查元数据决策和调用方到底保留、替换了哪些字节，不是只确认一个布尔返回值看起来正确。

这个库不会代替调用方发请求、重试、安排后台任务或保存正文。断言只覆盖一个匹配的热缓存条目和这组无冲突策略，不覆盖网络超时处理、所有指令组合或完整 CDN。部署验收仍需沿真实链路测试冷缓存、窗口耗尽和故障恢复，并确认允许的陈旧程度没有越过该资源的正确性要求。

来源

RFC 5861：陈旧控制，扩展窗口和符合条件的错误状态，已核验 2026-09-07。
RFC 9111：提供陈旧响应，陈旧复用限制，已核验 2026-09-07。
http-cache-semantics 4.2.0，重验证决策和调用方负责的正文存储，已核验 2026-09-07。

韧性 · XB 现场笔记

缓存集中失效会放大回源工作

在真实边界内合并工作

错开时间不能改变新鲜度承诺

坏掉的样子

快速验证

延伸阅读

来源

熔断器阻止对故障服务的轰炸

明确政策，而不只是画出状态

分类失败，并限定影响范围

恢复是一场受控试探

坏掉的样子

快速验证

延伸阅读

来源

陈旧缓存需要有界策略

用可用性换新鲜度

如何表示

坏掉的样子

快速验证

延伸阅读

来源