缓存 on 吾爱主机

DNS 递归解析与缓存：TTL、负缓存与 dig 排障

Mon, 03 Aug 2026 00:00:00 +0800

浏览器访问一个域名时，应用通常只发出一次 DNS 查询，但这不等于某台服务器“一次查完全部答案”。在常见架构中，本机的存根解析器把问题交给递归解析器；递归解析器先查缓存，未命中时再从根、顶级域到权威服务器逐级追踪委派关系。

理解这条链路，才能解释许多看似矛盾的现象：记录已经修改，为什么有些用户仍看到旧地址？域名明明存在，为什么查询某种类型却没有答案？为什么 dig +trace 正常，业务使用的 DNS 却返回 SERVFAIL？本文从协议机制出发，给出可复现的观察方法和分层排障流程。

一、先分清四个角色

一次典型查询涉及四类角色：

角色	职责	常见位置
存根解析器（stub resolver）	接收应用请求并转交给配置的 DNS 服务器	操作系统、容器运行时
递归解析器	代客户端寻找最终答案，并维护缓存	企业 DNS、运营商 DNS、公共 DNS
根与 TLD 服务器	返回下一层权威服务器的委派信息	根区、`.com`、`.cn` 等
权威服务器	对自己管理的区域给出权威答案	域名托管商或自建 DNS

RFC 1034 区分了递归与迭代：递归服务要么返回最终答案，要么返回错误，不把委派直接丢给普通客户端；迭代查询则允许服务器返回“下一步去问谁”的 referral。递归解析器正是通过多次迭代查询完成客户端委托。

以查询 www.example.com A 为例，缓存全部未命中时，路径可抽象为：

应用
 -> 存根解析器
 -> 递归解析器
 -> 根服务器：去问 .com
 -> .com 服务器：去问 example.com 的权威服务器
 -> 权威服务器：返回 www.example.com 的 A 记录
 <- 缓存结果并把答案返回应用

委派响应通常在 Authority 区给出 NS 记录；必要时，Additional 区还会附带 glue 地址，避免为了寻找某个名字服务器的地址而形成解析循环。若目标是 CNAME，解析器还要继续解析其目标名称，因此别把“查到 CNAME”误认为已经获得可连接的 IP。

二、缓存的核心不是“有或没有”，而是剩余 TTL

资源记录中的 TTL 以秒为单位，表示记录可以在缓存中保留多久。递归解析器返回缓存答案时，客户端看到的通常是递减后的剩余 TTL，而不是权威区文件里的初始值。

可以连续观察：

dig @1.1.1.1 example.com A +noall +answer
sleep 10
dig @1.1.1.1 example.com A +noall +answer

如果两次命中同一缓存节点，第二次 TTL 通常会减少约 10 秒；若中途刷新、负载均衡到另一节点或记录被预取，数值也可能跳变。TTL 归零后表示该缓存副本不应继续使用，但并不意味着全世界会在同一时刻刷新：不同递归解析器的首次查询时间不同，各自的过期时刻也不同。

因此，变更记录时应把传播过程理解为“旧缓存逐个过期”，而不是权威服务器主动推送。工程上可以在计划变更前至少一个旧 TTL 周期先降低 TTL，等待旧缓存自然淘汰后再切换地址；完成并稳定运行后再恢复 TTL。临时改低 TTL 无法让已经缓存的高 TTL 记录提前失效。

缓存还可能存在于多个层次：

应用内部 -> 操作系统 -> 本地缓存服务 -> 企业/运营商递归解析器

只清理浏览器缓存不一定有效；反过来，公共递归解析器已更新，也不代表长连接、连接池或应用自己的地址缓存已经更新。排障时必须明确每次查询实际经过哪一层。

三、负缓存：不存在的答案也会被记住

DNS 不只缓存成功答案。RFC 2308 定义了负缓存，并区分两个常被混淆的结果：

NXDOMAIN：查询的名称不存在；
NODATA：名称存在，但没有所查询类型的记录。它不是单独的 DNS RCODE，需要根据响应内容判断。

例如，某名称有 A 记录但没有 AAAA 记录，查询 AAAA 可能得到 NODATA，而不是 NXDOMAIN。把两者混为一谈，会误导监控和故障处理。

权威服务器返回负答案时，会在 Authority 区携带区域 SOA。按照 RFC 2308，负缓存 TTL 取 SOA 记录自身 TTL 与 SOA.MINIMUM 字段中的较小值，并像普通缓存 TTL 一样递减；到零后该负答案不能继续使用。这解释了一个常见故障：先查询了尚未创建的名称，递归解析器缓存 NXDOMAIN，随后即使权威端补上记录，部分客户端仍要等负缓存过期。

观察负答案时不要只看 Answer 区：

dig @1.1.1.1 does-not-exist.example.com A

重点检查：

status 是 NXDOMAIN、NOERROR 还是 SERVFAIL；
Authority 区是否有 SOA；
SOA 的剩余 TTL 是否递减；
同名查询其他类型时结果是否不同。

SERVFAIL 与 NXDOMAIN 含义不同。前者表示服务器未能完成处理，可能来自上游超时、DNSSEC 验证失败、委派错误或权威服务器不可达；不要把它解释成“域名不存在”，也不要用创建一条记录来盲目修复。

四、用 dig 分层观察，而不是只换一个公共 DNS

1. 查询系统实际使用的递归解析器

dig example.com A

输出中的 SERVER 表明请求发给了谁；标志位中的 rd 表示客户端请求递归，ra 表示服务器声明可提供递归。注意，ra 是能力声明，不代表这一次一定完成了完整递归过程，答案也可能直接来自缓存。

2. 对比不同递归解析器

dig @1.1.1.1 example.com A +noall +answer +comments
dig @8.8.8.8 example.com A +noall +answer +comments

若答案或剩余 TTL 不同，先考虑缓存时间点、地理调度和 EDNS Client Subnet 等差异，不要立刻断定某个解析器“错误”。

3. 直接询问权威服务器

先找权威 NS，再向其中一台发非递归查询：

dig example.com NS +short
dig @a.iana-servers.net example.com A +norecurse

ISC BIND 的 dig 文档说明，+norecurse 会清除查询中的 RD 位。直接比较权威答案和递归答案，可以判断问题在权威配置还是缓存层。若多个权威节点答案不一致，应检查区文件发布、序列号和节点同步，而不是等待递归缓存自行“修好”。

4. 用 trace 重放委派链

dig +trace example.com A

+trace 从根服务器开始按委派向下查询，并自动关闭递归请求。它适合发现缺失 glue、错误 NS、某层委派不一致等问题。但它绕开了业务正在使用的递归解析器，因此“trace 成功”只能说明从当前主机进行迭代追踪大体可行，不能证明企业 DNS 的缓存、转发器或 DNSSEC 验证链没有故障。

5. 必要时强制 TCP

dig +tcp example.com A

当响应被截断、UDP 路径受限或怀疑防火墙只放行了一种传输时，对比 UDP 与 TCP 很有价值。不要沿用“DNS 永远只用 UDP 53”的排障假设；生产网络应同时验证所需的 UDP/TCP 53 路径。

五、一个可执行的排障顺序

遇到“域名解析异常”，可以按以下顺序收敛范围：

记录现场：保存查询名、类型、时间、客户端网络、SERVER、状态码、flags 和完整响应；
确认名称与类型：A、AAAA、CNAME、TXT 是不同问题，NXDOMAIN 与 NODATA 也不同；
比较递归与权威：权威正确而递归旧，多半是缓存；权威节点之间不同，则先修权威发布；
检查 TTL：同时查看正答案和 SOA 驱动的负缓存，不要只看控制台显示的配置值；
追踪委派：用 +trace 检查根到权威的链路，并核对父区 NS/glue 与子区实际服务；
比较网络与传输：更换客户端网络，分别测试 UDP/TCP，检查防火墙、NAT 和 MTU；
最后再清缓存：清理动作要针对真正缓存旧结果的层，且应保留清理前证据。

一个实用的证据包可以这样采集：

name=example.com
{
 date -u
 dig "$name" A
 dig "$name" AAAA
 dig "$name" NS
 dig +trace "$name" A
 dig +tcp "$name" A
} > dns-debug.txt

生产环境还应把实际递归服务器地址、权威节点查询结果和变更时间线加入证据包。这样即使故障已经因 TTL 到期而消失，也能回溯当时究竟是旧缓存、负缓存、委派还是网络路径问题。

六、工程设计建议

TTL 是一致性与查询成本的权衡：低 TTL 缩短变更窗口，但会增加权威查询量，并不能替代健康检查与故障转移设计；
先设计回滚再改 DNS：保留旧服务一段时间，避免旧缓存用户立即失去服务；
监控要覆盖多层：既从公共递归解析器查询，也直接检查每个权威节点；
不要依赖单一记录类型：双栈环境同时监控 A 与 AAAA，防止 IPv4 正常而 IPv6 路径故障；
区分控制面与数据面：托管控制台显示“已保存”只证明配置已提交，不等于所有权威节点、递归缓存和客户端都已收敛。

总结

DNS 故障的关键不是记住更多刷新缓存命令，而是建立分层模型：存根解析器把请求交给递归解析器，递归解析器通过 referral 逐级找到权威答案，再按 TTL 缓存；不存在的名称或类型也可能通过 SOA 形成负缓存。排障时把权威、递归、客户端缓存和网络传输逐层拆开，并结合 status、flags、Authority 区与剩余 TTL 取证，通常能比“反复切换 DNS”更快定位根因。

参考资料

HTTP 条件请求与缓存协商：ETag、Last-Modified 与 Cache-Control 工程实践

Wed, 15 Jul 2026 00:00:00 +0800

很多系统的“慢”并不在业务逻辑，而在重复传输不变的响应体。浏览器、CDN、反向代理都可能持有一份旧副本；真正关键的是：这份副本还能不能直接用？如果不能直接用，能否只问服务器“变了没有”？

HTTP 把这件事拆成两层：

新鲜度（freshness）：缓存还在不在有效期内，决定要不要立刻回源；
验证（validation）：过期或必须再确认时，用条件请求做协商，成功则返回 304 Not Modified，避免再次传输实体。

本文基于 HTTP 语义规范（RFC 9110）与 HTTP 缓存规范（RFC 9111），结合 Nginx 能力，讲清楚 Cache-Control、ETag / Last-Modified、If-None-Match / If-Modified-Since 的协作关系，以及可落地的配置与排错方法。

一、先分清：存下来 ≠ 可以直接用

RFC 9111 把缓存决策大致分成：

阶段	问题	关键概念
存储（store）	响应能不能进缓存	方法、状态码、`no-store`、`private`、`Authorization` 等
新鲜度（fresh）	已存副本是否仍 fresh	`max-age` / `s-maxage` / `Expires` / Age
验证（validate）	stale 后能否复用	条件请求 + 校验器（validator）
复用（reuse）	最终回什么	200 全量、304 无 body、或回源新响应

常见误解：

no-cache 不是“禁止缓存”。它表示：可以用存储副本，但必须先成功验证后才能拿去满足其他请求。
no-store 才是“不要存”。缓存不得存储该请求/响应的任何部分，也不能拿它去满足别的请求。
private 不是“浏览器也不能缓存”。它限制的是共享缓存（CDN、公司代理）：响应面向单个用户；私有缓存（浏览器）仍可在规则允许下存储。

把语义说清楚，后面的工程配置才不会互相打架。

二、新鲜度：Cache-Control 的核心指令

1. 响应侧最常用指令

指令	含义（工程视角）
`max-age=N`	响应在 age > N 秒后视为 stale
`s-maxage=N`	只对共享缓存覆盖 `max-age`/`Expires`；并带有必须再验证后才能复用 stale 的语义
`public`	明确允许缓存（例如带 `Authorization` 的响应在共享缓存中的场景）
`private`	禁止共享缓存存储（或限定字段）
`no-cache`	使用前必须验证
`no-store`	不要存储
`must-revalidate`	一旦 stale，不得在未验证成功前复用；断连时更应报错而不是偷偷给 stale

一个可记的分层：

# 静态资源：可公开、长期缓存（内容指纹化后）
Cache-Control: public, max-age=31536000, immutable

# HTML 入口：可缓存但每次用前确认
Cache-Control: no-cache

# 登录态 API：不要被中间层存
Cache-Control: private, no-store

# 对一致性要求高的共享缓存内容
Cache-Control: public, max-age=60, must-revalidate

2. Age 与“看起来刚生成”

响应里的 Age 表示估计已在缓存中停留的秒数。共享缓存命中时，客户端看到的“年龄”往往不是 0。排查“为什么我设了 max-age=60，却总在提前回源”时，要同时看：

源站给出的 Cache-Control / Expires
中间层是否改写了头
响应是否已有较大 Age

3. 启发式新鲜度：别依赖“没写过期时间也碰巧能缓存”

没有显式过期信息时，部分缓存会用启发式算法估算 fresh 时间。这在不同实现间差异大，生产环境应显式给出 freshness，不要赌默认行为。

三、校验器：ETag 与 Last-Modified

验证阶段依赖表示元数据（representation metadata），最常见两类：

1. `Last-Modified`

源站认为所选表示最后修改的时间（HTTP-date）。例如：

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

优点：实现简单，文件系统/对象存储天然具备 mtime。
局限：

秒级精度，一秒内多次变更可能撞车；
时钟回拨、多副本 mtime 不一致会误判；
内容没变但元数据变了时，语义可能不够准。

2. `ETag`（实体标签）

ETag 是源站为某个表示分配的不透明标签：

ETag: "xyzzy"
ETag: W/"xyzzy"

强校验器（strong）：表示数据（以及会影响 200 内容的关键元数据）变化时标签应变化。适合字节级精确比较。
弱校验器（weak，W/ 前缀）：语义等价即可，即使字节不完全相同。生成成本更低，但比较能力更弱。

RFC 9110 明确：在不便存修改时间、一秒精度不够、或修改时间维护不一致时，ETag 通常比 Last-Modified 更可靠。

工程上常见生成策略：

策略	适用	注意
内容哈希（SHA-256 截断）	静态文件、构建产物	强 ETag，成本随体积上升
版本号 / 修订号	业务资源、CMS	发布流程必须保证“内容变则版本变”
inode + size + mtime	传统文件服务器	迁移/复制后可能变，跨机一致性差
弱 ETag（模板渲染摘要）	HTML 片段语义不变	不要拿去当字节级一致性保证

四、条件请求：如何问“变了没有”

1. `If-None-Match`（优先，基于 ETag）

客户端/缓存带上已存表示的 ETag：

GET /app.js HTTP/1.1
Host: example.com
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

源站比较当前 ETag：

匹配（表示未变）→ 304 Not Modified，通常无 body；
不匹配 → 200 OK + 新表示（含新的 ETag）。

对 If-None-Match，规范要求使用弱比较函数：即使只有弱 ETag，也可用于缓存验证。

2. `If-Modified-Since`（基于时间）

GET /style.css HTTP/1.1
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

若所选表示的修改时间不比该日期更新，则不必再传实体。

3. 两者同时出现时谁说了算？

RFC 9110 规定：若请求里带了 If-None-Match，接收方必须忽略 If-Modified-Since——因为实体标签被认为是更准确的替代条件。两者同时出现多是兼容历史客户端；服务端实现应按规范优先级处理。

4. `304 Not Modified` 到底省了什么

304 表示：若没有条件约束，这次本应是 200；但条件为假（未修改），客户端应继续使用本地已存表示。

源站仍应带上在同等 200 中会发送的关键头（如 ETag、Date、Content-Location 等），以便缓存刷新元数据（freshen），而不只是“空响应”。

流量层面：

首次：200 + 完整 body（例如 800KB）
之后未变更：304 + 几乎无 body（通常几百字节头）

对静态资源、移动端弱网、跨境回源，收益非常明显。

五、一张图串起完整路径

Client/CDN 本地有副本？
 |
 | 无 -----> 普通 GET -----> 200 + body + Cache-Control + ETag/LM
 |
 | 有且 fresh -----> 直接复用（不回源）
 |
 | 有但 stale / 或 no-cache
 v
 条件请求：If-None-Match / If-Modified-Since
 |
 +--> 未变：304（刷新头，复用旧 body）
 |
 +--> 已变：200（新 body + 新校验器）

记住两句话：

fresh 解决“要不要问”；
validator 解决“问了以后要不要传 body”。

只有 max-age 没有校验器，过期后往往只能全量回源；只有 ETag 没有合理 freshness，会变成“每次都协商”，仍然浪费 RTT。

六、工程实践：按资源类型给策略

1. 带内容哈希的静态资源（最推荐）

构建后文件名含 hash，例如 app.3f2a1c.js：

location /static/ {
 # 文件名已指纹化，可大胆长缓存
 expires 365d;
 add_header Cache-Control "public, max-age=31536000, immutable";
}

要点：

URL 变 = 内容变，可用超长 max-age；
immutable 提示浏览器在 freshness 内不必做启发式再验证（支持情况因客户端而异，但不妨碍给出）；
旧 URL 自然失效，无需纠结主动 purge 每一个文件。

2. HTML / 入口文档

入口常引用带 hash 的静态资源，自身却要尽快看到新版本：

Cache-Control: no-cache
ETag: "html-rev-42"

或短 max-age + 强制再验证：

Cache-Control: max-age=0, must-revalidate
ETag: "html-rev-42"

这样浏览器/边缘仍可存副本，但使用前会走条件请求；HTML 未变则 304，变了才下新文档。

3. 个性化或含凭证的 API

Cache-Control: private, no-store

原因：

private 避免 CDN 把用户 A 的响应给用户 B；
no-store 进一步降低敏感信息落盘风险。

注意：no-store 不是完备隐私方案（恶意或失控缓存可能不遵守），敏感数据仍要靠鉴权、最小化返回字段和传输安全。

4. 可被 CDN 缓存的公共 API / 配置

Cache-Control: public, s-maxage=30, max-age=10
ETag: "cfg-20260715-1"

浏览器短缓存（max-age）；
CDN 稍长（s-maxage）；
过期后用 ETag 协商，降低源站带宽。

Nginx 反代缓存可配合：

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:50m inactive=10m;

location /api/public/ {
 proxy_cache api_cache;
 proxy_cache_valid 200 30s;
 # 过期后用条件请求回源校验
 proxy_cache_revalidate on;
 # 更新期间允许短暂提供 stale，降低源站抖动影响
 proxy_cache_use_stale updating error timeout http_500 http_502 http_503;
 proxy_pass http://upstream;
}

proxy_cache_revalidate on 的作用，正是在缓存过期后启用 If-Modified-Since / If-None-Match 条件回源——这与 RFC 里的 validation 模型一致。

七、服务端如何正确实现条件 GET

以伪代码说明最小正确逻辑：

def handle_get(request, resource):
 etag = resource.strong_etag() # 例如 '"%s"' % sha256(body)[:16]
 last_mod = resource.last_modified_http_date()

 # 1) 优先处理 If-None-Match
 inm = request.headers.get("If-None-Match")
 if inm:
 if etag_matches(inm, etag): # 按弱比较规则实现
 return response_304(etag=etag, last_modified=last_mod)
 return response_200(resource, etag=etag, last_modified=last_mod)

 # 2) 否则再看 If-Modified-Since
 ims = request.headers.get("If-Modified-Since")
 if ims and not resource.modified_after(ims):
 return response_304(etag=etag, last_modified=last_mod)

 return response_200(resource, etag=etag, last_modified=last_mod)

实现清单：

同一表示的 ETag 必须稳定：相同内容不要每次随机；
内容变更必须换 ETag：漏更新会造成“改了却一直 304”；
Vary 要配对：若响应随 Accept-Encoding / Authorization / 自定义头变化，必须正确 Vary，否则缓存会串内容；
压缩前后一致性：对 gzip/br 内容，ETag 策略要与表示选择一致，避免“协商错表示”；
不要手动拼错弱标记：W/ 大小写敏感，格式为 W/"tag"。

八、常见坑与排查清单

坑 1：`no-cache` 和 `no-store` 用反

想“每次确认后再用本地副本” → no-cache（或 max-age=0, must-revalidate）+ ETag；
想“别存敏感响应” → no-store（通常再加 private）。

坑 2：只配了长缓存，没有内容指纹

Cache-Control: max-age=31536000 配在固定 URL 的 app.js 上，发版后用户会长时间用旧脚本。正确做法是 hash 文件名 或主动缩短 freshness 并保证能 purge。

坑 3：ETag 在多实例间不一致

滚动发布时实例 A/B 对同一文件算出不同 ETag（例如混入了进程启动时间），客户端会在 200/304 间抖动，缓存命中率暴跌。校验器生成必须内容决定论。

坑 4：中间层剥掉了校验器或改写了 Cache-Control

排查命令：

# 看源站
curl -sI https://origin.example.com/static/app.js | sed -n '1,20p'

# 看经 CDN/Nginx 后
curl -sI https://www.example.com/static/app.js | sed -n '1,20p'

# 模拟条件请求
ETAG='"abc123"'
curl -sI -H "If-None-Match: $ETAG" https://www.example.com/static/app.js | sed -n '1,15p'

对比：ETag、Cache-Control、Age、CF-Cache-Status/X-Cache 等是否符合预期。第二次应看到 304（在 ETag 仍匹配时）。

坑 5：API 被共享缓存误缓存

带 cookie/authorization 的响应若缺少 private/no-store，再叠加错误的 public，可能把用户数据缓存到边缘。对用户相关响应默认保守，对真正公共的 GET 再显式放开。

坑 6：304 后客户端仍像“没更新样式”

常见是 HTML 长缓存，或 Service Worker / 应用内二次缓存。协议层 304 只保证这一跳 HTTP 缓存协商；还要检查：

HTML 的 Cache-Control；
SW 的 cache.addAll 策略；
应用本地 localStorage 里的资源清单。

九、选型小结

目标	推荐组合
最大化静态资源性能	内容哈希 URL + 长 `max-age` + `public`
入口文档尽快更新	`no-cache` 或短 max-age + ETag + 304
公共只读 API 降源站负载	`s-maxage` + ETag + CDN `proxy_cache_revalidate`
用户私有数据	`private, no-store`，默认不进共享缓存
过期后仍要强一致	`must-revalidate` / `proxy-revalidate` / `s-maxage` 语义

原则：

用 freshness 控制回源频率；
用 validator 控制回源体积；
用 private/no-store 控制安全边界；
用 URL 指纹解决“长缓存与发布”的矛盾。

总结

HTTP 缓存不是“加一个 Redis”或“在 Nginx 里 proxy_cache on”这么简单，它是一套有严格语义的协议机制：

Cache-Control 回答能不能存、能存多久、过期后能不能直接用；
ETag / Last-Modified 回答如何证明表示是否变化；
If-None-Match / If-Modified-Since 与 304 回答如何在确认未变时省略 body。

把这三层设计对齐后，静态站点、前后端分离入口、CDN 边缘缓存和公共 API 都能在带宽、延迟、一致性之间取得可解释的平衡。下次再看到“用户一直是旧页面”或“源站带宽无故升高”，先把响应头和一次条件请求抓出来——答案通常就在 Cache-Control 与校验器的协作里。

参考资料

IETF RFC 9111：HTTP Caching（新鲜度、验证、Cache-Control 指令语义）
IETF RFC 9110：HTTP Semantics（ETag、Last-Modified、If-None-Match、If-Modified-Since、304 Not Modified）
MDN：HTTP caching
MDN：ETag
MDN：If-None-Match
MDN：Cache-Control
Nginx 文档：ngx_http_headers_module（expires / add_header）
Nginx 文档：ngx_http_proxy_module（proxy_cache_revalidate、proxy_cache_use_stale、proxy_cache_valid）

Redis 缓存穿透、击穿与雪崩：原理、场景与工程解法

Mon, 13 Jul 2026 00:00:00 +0800

在高并发系统里，Redis 常常被放在数据库前面做读加速。一旦缓存设计不当，问题往往不是“Redis 慢一点”，而是数据库被瞬间打穿。工程上最常见、也最容易被混为一谈的三类故障是：缓存穿透、缓存击穿和缓存雪崩。

这三类问题听起来相似，根因却不同：

问题	典型特征	直接伤害
缓存穿透	查的是不存在的数据，缓存和 DB 都没有	恶意或异常请求反复打到 DB
缓存击穿	某个热点 key 刚好过期	同一时刻大量请求打到 DB
缓存雪崩	大量 key 同时失效，或缓存层整体不可用	系统级读流量直接压垮 DB

本文从现象、根因、可落地方案三层拆开，并结合 Redis 官方能力（SET 的 NX/EX、EXPIRE、淘汰策略、分布式锁模式）给出可复用实践。

一、先把请求路径画清楚

一个典型读路径是：

Client -> App -> Redis -> (miss) -> Database -> write back Redis -> response

缓存层的价值在于：

把高频读从数据库剥离出来；
用更低延迟响应热点数据；
给数据库争取容量和稳定性。

因此，任何“绕过缓存直接打 DB”的路径，都要被当成故障设计点来处理。

二、缓存穿透：查不存在的数据

1. 现象

请求的 key 在业务上不存在，例如：

用户 ID -1
商品 ID 999999999
被爬虫扫出来的非法参数

此时 Redis 没有缓存，数据库也查不到记录。如果应用只在“查到结果时才写缓存”，那么每次请求都会落到数据库。

2. 根因

穿透的本质不是“缓存过期”，而是：

空结果没有被负缓存（negative caching）保护。

3. 解法

方案 A：缓存空对象（最常用）

查库为空时，也写入一个短 TTL 的空值标记：

# 伪命令：空结果缓存 60 秒
SET product:999999999 __NULL__ EX 60

应用读到 __NULL__ 时直接返回“不存在”，不再访问数据库。

注意：

TTL 不要太长，避免真实数据刚创建后长时间读不到；
空值要有统一约定，避免和正常业务值冲突；
对写路径做缓存失效/更新，保证最终一致。

方案 B：布隆过滤器（Bloom Filter）前置拦截

对“可能存在”的 ID 集合做布隆过滤器：

数据写入时同步/异步加入过滤器；
查询前先判断“一定不存在还是可能存在”；
一定不存在则直接拒绝，不打 Redis/DB。

适合海量 ID、爬虫扫描、开放查询接口。代价是：

有极低误判率（把不存在判断成可能存在）；
需要维护过滤器更新与扩容。

方案 C：参数与权限校验前置

很多穿透其实是脏流量：

非数字 ID
超范围分页
未登录却访问私有资源

在网关/应用入口直接拦截，比把压力交给缓存更划算。

三、缓存击穿：热点 key 刚好失效

1. 现象

某个非常热的 key（首页配置、秒杀库存视图、热门商品详情）在某一瞬间过期。
下一毫秒，成千上万请求同时看到 miss，一起去查数据库，形成“单点热点打穿”。

2. 根因

击穿关注的是：

单个热点 key 过期窗口内的并发回源。

它和穿透不同：数据本来存在，只是缓存刚好空了。

3. 解法

方案 A：互斥重建（singleflight / 分布式锁）

只有一个请求负责回源重建，其他请求等待或短暂失败重试。

Redis 官方 SET 支持原子条件写入，可用 NX + EX 做互斥：

# 抢重建锁，5 秒自动过期，防止进程崩溃后死锁
SET rebuild:lock:product:1001 1 NX EX 5

流程：

读缓存 miss；
SET lock NX EX 抢锁；
抢到锁的请求查 DB，写回缓存，释放锁；
没抢到锁的请求短暂 sleep/重试读缓存，或返回旧兜底。

官方文档明确：SET key value NX EX seconds 是设置值并带过期时间的常用原子写法；SETNX 在新代码中更推荐用 SET ... NX 替代。

方案 B：逻辑过期（logical expire）

缓存 value 内嵌业务过期时间，物理 key 不过期或过期很久：

{
 "data": {"id": 1001, "price": 99},
 "expireAt": 1720857600
}

读取时：

未逻辑过期：直接返回；
已逻辑过期：返回旧数据，同时异步触发重建。

优点是用户几乎无感 miss；代价是要接受短暂脏读，并做好异步重建失败补偿。

方案 C：热点 key 永不过期 + 主动更新

对真正的超级热点，不依赖 TTL 被动失效，而由写路径/定时任务主动更新。
TTL 更适合普通数据；热点数据更适合“写时更新 + 监控”。

四、缓存雪崩：大面积失效或缓存层故障

1. 现象

两类雪崩最常见：

过期雪崩：大量 key 在同一时间点过期；
可用性雪崩：Redis 集群故障、网络分区、连接打满，导致缓存层整体不可用。

结果都是数据库在短时间内接到远超容量的读请求。

2. 根因

雪崩的核心不是某一个 key，而是：

缓存保护面在同一时间失效，流量失去缓冲层。

3. 解法

方案 A：TTL 加随机抖动

不要让同类数据使用完全相同的过期时间：

ttl = base_ttl + random(0, jitter)
# 例如 3600 + random(0, 300)

这样可以把过期曲线打散，避免整点集体回源。

方案 B：多级缓存与本地缓存

本地 Caffeine/Guava Cache 挡住进程内重复读；
Redis 作为分布式缓存；
DB 作为最终数据源。

本地缓存 TTL 更短，可显著降低 Redis 抖动对 DB 的传导。

方案 C：限流、熔断、降级

缓存层异常时，应用不能无脑回源：

对回源 QPS 做令牌桶/漏桶限流；
数据库错误率升高时熔断；
非核心接口返回兜底页/默认配置；
核心读接口优先返回短暂旧数据。

方案 D：正确使用 Redis 内存淘汰策略

当 Redis 用作缓存时，官方建议配置最大内存和淘汰策略，以便内存触顶时按策略驱逐 key，而不是写失败或无规划崩溃。常见策略包括：

allkeys-lru / allkeys-lfu：在全部 key 中淘汰；
volatile-lru / volatile-lfu / volatile-ttl：只在设置了过期时间的 key 中淘汰。

关键点：

缓存场景应显式设置 maxmemory；
按业务选择 LRU/LFU；
监控 evicted_keys、命中率、内存使用，避免“默默淘汰关键数据”却无人知晓。

淘汰策略解决的是内存压力下的可持续性，不能替代业务层的穿透/击穿防护，但能降低缓存层自身失控概率。

五、一套可落地的组合策略

真实系统很少只选一种方案，更常见的是分层组合：

1. 入口校验：挡住非法参数
2. 布隆过滤器/存在性索引：挡住明显不存在的 key
3. Redis 读：命中则返回
4. miss 时：
 - 热点 key：互斥重建或逻辑过期
 - 普通 key：允许有限并发回源
5. DB 空结果：写短 TTL 空缓存
6. DB 有结果：写缓存，TTL 加抖动
7. 全链路：限流 + 熔断 + 监控告警

伪代码示例

def get_product(product_id: str):
 if not valid_id(product_id):
 return None

 if bloom and not bloom.might_contain(product_id):
 return None

 cached = redis.get(f"product:{product_id}")
 if cached == "__NULL__":
 return None
 if cached is not None:
 return decode(cached)

 # 热点互斥重建
 locked = redis.set(f"rebuild:lock:product:{product_id}", "1", nx=True, ex=5)
 if not locked:
 time.sleep(0.05)
 return get_product(product_id) # 简化：重试读缓存

 try:
 row = db.query_product(product_id)
 if row is None:
 redis.set(f"product:{product_id}", "__NULL__", ex=60)
 return None
 redis.set(f"product:{product_id}", encode(row), ex=3600 + random.randint(0, 300))
 return row
 finally:
 redis.delete(f"rebuild:lock:product:{product_id}")

说明：

SET ... NX EX 用于短锁，避免击穿时并发回源；
空值缓存用于防穿透；
TTL 抖动用于打散过期，降低雪崩概率。

六、排查清单：线上怎么快速判断是哪一种

1. 先看指标

Redis 命中率是否骤降
Redis 连接数/超时是否升高
数据库 QPS、慢查询、连接池是否打满
是否集中在某几个 key，还是大面积 key

2. 判断路径

观察	更可能是
大量非法/不存在 ID，DB 查空很多	穿透
单个热 key 流量尖峰，过期瞬间 DB 飙升	击穿
整点或批次任务后大面积 miss	过期雪崩
Redis 超时/主从切换/集群异常同时发生	可用性雪崩

3. 临时止血

对异常查询参数限流；
对热点 key 预热并临时延长 TTL；
打开空值缓存；
给 DB 回源加总开关/配额；
非核心读降级。

七、设计原则总结

缓存不是数据库的影子，是保护层。 任何 miss 路径都要有预算。
空结果也是结果。 不做负缓存，就容易被穿透。
热点不能靠“碰巧没过期”。 要有互斥重建、逻辑过期或主动更新。
过期时间要工程化。 相同 TTL 是雪崩温床，抖动是基本操作。
缓存故障要有降级。 没有限流和熔断的缓存架构，只是把风险延后到数据库。
可观测性比“感觉很快”更重要。 命中率、回源 QPS、淘汰数、锁竞争都要可监控。

八、什么时候不该过度设计

不是所有系统都要上布隆过滤器 + 逻辑过期 + 多级缓存：

读 QPS 不高、数据几乎都存在：做好空值缓存和基础 TTL 即可；
写极少、读极多的配置类数据：适合主动更新 + 较长 TTL；
强一致要求极高的余额/库存：缓存只能做辅助，核心以数据库/专用组件为准，并明确一致性模型。

架构选择应匹配流量模型和一致性要求，而不是堆名词。

总结

缓存穿透、击穿、雪崩并不是三个神秘黑话，而是三条清晰的失败路径：

穿透：不存在的数据反复打穿 DB；
击穿：热点 key 失效瞬间被并发打穿；
雪崩：保护面大面积失效，流量失去缓冲。

把问题定义清楚后，解法会自然收敛到：入口校验、空值缓存、互斥重建、TTL 抖动、淘汰策略、限流熔断与监控。
Redis 提供了 SET NX/EX、EXPIRE、内存淘汰和分布式锁模式等基础能力，但真正决定系统稳不稳的，是你有没有把这些能力嵌进完整的读路径设计里。

参考资料

Redis 官方文档：SET 命令（含 NX / EX 等选项）
Redis 官方文档：EXPIRE 命令
Redis 官方文档：SETNX 命令
Redis 官方文档：Key eviction 内存淘汰策略
Redis 官方文档：Distributed locks 分布式锁模式

缓存 on 吾爱主机

DNS 递归解析与缓存：TTL、负缓存与 dig 排障

一、先分清四个角色

二、缓存的核心不是“有或没有”，而是剩余 TTL

三、负缓存：不存在的答案也会被记住

四、用 dig 分层观察，而不是只换一个公共 DNS

1. 查询系统实际使用的递归解析器

2. 对比不同递归解析器

3. 直接询问权威服务器

4. 用 trace 重放委派链

5. 必要时强制 TCP

五、一个可执行的排障顺序

六、工程设计建议

总结

参考资料

HTTP 条件请求与缓存协商：ETag、Last-Modified 与 Cache-Control 工程实践

一、先分清：存下来 ≠ 可以直接用

二、新鲜度：Cache-Control 的核心指令

1. 响应侧最常用指令

2. Age 与“看起来刚生成”

3. 启发式新鲜度：别依赖“没写过期时间也碰巧能缓存”

三、校验器：ETag 与 Last-Modified

1. Last-Modified

2. ETag（实体标签）

四、条件请求：如何问“变了没有”

1. If-None-Match（优先，基于 ETag）

2. If-Modified-Since（基于时间）

3. 两者同时出现时谁说了算？

4. 304 Not Modified 到底省了什么

五、一张图串起完整路径

六、工程实践：按资源类型给策略

1. 带内容哈希的静态资源（最推荐）

2. HTML / 入口文档

3. 个性化或含凭证的 API

4. 可被 CDN 缓存的公共 API / 配置

七、服务端如何正确实现条件 GET

八、常见坑与排查清单

坑 1：no-cache 和 no-store 用反

坑 2：只配了长缓存，没有内容指纹

坑 3：ETag 在多实例间不一致

坑 4：中间层剥掉了校验器或改写了 Cache-Control

坑 5：API 被共享缓存误缓存

坑 6：304 后客户端仍像“没更新样式”

九、选型小结

总结

参考资料

Redis 缓存穿透、击穿与雪崩：原理、场景与工程解法

一、先把请求路径画清楚

二、缓存穿透：查不存在的数据

1. 现象

2. 根因

3. 解法

方案 A：缓存空对象（最常用）

方案 B：布隆过滤器（Bloom Filter）前置拦截

方案 C：参数与权限校验前置

三、缓存击穿：热点 key 刚好失效

1. 现象

2. 根因

3. 解法

方案 A：互斥重建（singleflight / 分布式锁）

方案 B：逻辑过期（logical expire）

方案 C：热点 key 永不过期 + 主动更新

四、缓存雪崩：大面积失效或缓存层故障

1. 现象

2. 根因

3. 解法

方案 A：TTL 加随机抖动

方案 B：多级缓存与本地缓存

方案 C：限流、熔断、降级

方案 D：正确使用 Redis 内存淘汰策略

五、一套可落地的组合策略

伪代码示例

六、排查清单：线上怎么快速判断是哪一种

1. 先看指标

2. 判断路径

3. 临时止血

七、设计原则总结

八、什么时候不该过度设计

总结

参考资料

1. `Last-Modified`

2. `ETag`（实体标签）

1. `If-None-Match`（优先，基于 ETag）

2. `If-Modified-Since`（基于时间）

4. `304 Not Modified` 到底省了什么

坑 1：`no-cache` 和 `no-store` 用反