面试题手册

CDN 边缘计算是什么？CDN 边缘计算是将计算能力从中心化源站下沉到 CDN 边缘节点，在靠近用户的网络边缘执行计算任务的一种架构模式。传统 CDN 只做静态内容缓存，而边缘计算让边缘节点具备了运行业务逻辑的能力——请求不必回源，直接在边缘节点处理并返回结果。两者的核心区别：CDN 解决的是"内容离用户更近"的问题，边缘计算解决的是"计算离用户更近"的问题。当两者结合，边缘节点既能缓存静态资源，又能执行动态计算，形成完整的边缘服务能力。为什么需要边缘计算？延迟：从数百毫秒到数十毫秒传统架构下，动态请求必须回源处理：用户 → 边缘节点 → 源站（可能跨区域）→ 返回，端到端延迟通常 200-500ms。边缘计算将计算逻辑部署到边缘节点，请求在本地完成处理，延迟可降至 10-50ms。对于实时交互场景（在线游戏、金融交易、视频直播），这几十到几百毫秒的差异直接影响用户体验和业务指标。回源压力与带宽成本没有边缘计算时，所有动态请求都打到源站，源站需要为每个请求分配 CPU、内存和网络资源。引入边缘计算后，大部分请求在边缘节点就地处理，只有少数需要中心数据的请求才回源。以 Cloudflare Workers 为例，官方数据显示边缘处理可节省至少 30% 的回源流量成本。数据合规与隐私各国数据本地化法规（如欧盟 GDPR、中国《数据安全法》）要求用户数据在本地处理。边缘计算让数据在产生地就近处理，减少跨境传输，既满足合规要求，又降低了数据泄露风险。核心应用场景1. API 网关与请求路由在边缘节点部署路由规则，根据 URL 路径、请求头、用户地域等信息将请求分发到不同的后端服务。好处是路由决策在离用户最近的位置完成，避免了不必要的回源往返。// Cloudflare Workers: 边缘 API 路由export default { async fetch(request) { const url = new URL(request.url); if (url.pathname.startsWith("/api/v1")) { return fetch("https://api-v1.example.com" + url.pathname + url.search); } if (url.pathname.startsWith("/api/v2")) { return fetch("https://api-v2.example.com" + url.pathname + url.search); } return new Response("Not Found", { status: 404 }); }};2. A/B 测试与个性化内容在边缘节点根据用户特征（地域、设备、Cookie 等）决定返回哪个版本的页面或接口数据。相比在源站做 A/B 分流，边缘分流避免了回源延迟，用户感知几乎为零。这也是电商、媒体平台常用的策略。// 边缘 A/B 测试export default { async fetch(request) { const country = request.cf?.country; if (country === "CN") { return fetch("https://cn-version.example.com" + new URL(request.url).pathname); } return fetch("https://global-version.example.com" + new URL(request.url).pathname); }};3. 图片与视频实时处理在边缘节点对图片进行缩放、裁剪、格式转换（WebP/AVIF），对视频流做转码或画质优化。请求到达边缘时，如果缓存中已有处理后的版本直接返回；没有则从源站取原始文件，在边缘处理后缓存并返回。这样源站只需存储一份原图，由边缘按需处理不同尺寸和格式。4. 认证鉴权将 JWT 验证、API Key 校验、权限检查等逻辑下沉到边缘节点。无效请求在边缘就被拦截，不会浪费源站资源。这对于高并发场景（秒杀、抢购）尤其重要，可以在边缘挡住大量未授权请求。5. 限流与防爬在边缘节点基于 IP、用户标识、请求频率等维度实施限流策略，识别并拦截爬虫和恶意请求。相比在源站做限流，边缘限流在请求进入内部网络前就完成过滤，防护效果更好。// 边缘限流示意（基于 IP）const rateLimiter = new Map();export default { async fetch(request) { const ip = request.headers.get("CF-Connecting-IP"); const now = Date.now(); const record = rateLimiter.get(ip); if (record && now < record.resetTime && record.count >= 100) { return new Response("Too Many Requests", { status: 429 }); } rateLimiter.set(ip, { count: (record?.count || 0) + 1, resetTime: now + 60000 }); return fetch(request); }};6. 数据聚合与智能缓存多个后端服务的响应可以在边缘节点聚合后统一返回给前端，减少前端的请求数量。同时，边缘节点可以对聚合结果设置智能缓存策略，后续相同请求直接返回缓存，无需再次回源。主流平台对比| 平台 | 运行时 | 语言支持 | 特点 ||------|--------|----------|------|| Cloudflare Workers | V8 隔离 | JS/TS/WASM | 全球节点最多（300+），免费额度慷慨 || AWS Lambda@Edge | Node.js/Python | JS/Python | 与 CloudFront + AWS 生态深度集成 || Fastly Compute@Edge | WASM | Rust/C++/JS | 基于 WebAssembly，冷启动极快 || Vercel Edge Functions | V8 隔离 | JS/TS | 与 Next.js 无缝配合 |选型建议：如果你需要全球覆盖和独立部署，选 Cloudflare Workers；如果技术栈在 AWS 生态内，选 Lambda@Edge；如果追求极致性能和冷启动速度，考虑 Fastly；如果是 Next.js 项目，Vercel Edge Functions 是最省事的选择。边缘计算的设计原则无状态优先：边缘节点随时可能被销毁或迁移，不要依赖本地变量或文件系统存储状态数据，应使用 KV 存储（如 Cloudflare KV）或外部数据库。优雅降级：边缘计算可能出现超时、节点不可用等情况，必须设计降级策略——返回缓存数据、展示兜底内容、或降级到源站处理，而不是直接报错。控制执行时间：各平台对边缘函数的执行时间有严格限制（Cloudflare Workers 免费版 CPU 时间 10ms，付费版 50ms；Lambda@Edge 超时 5-30s）。代码要尽量轻量，避免在边缘做重计算。冷启动问题：边缘函数在首次请求时会经历冷启动（加载代码 → 初始化运行时 → 执行函数）。保持代码体积小、减少外部依赖，可以有效缩短冷启动时间。面试回答要点回答"什么是 CDN 边缘计算"时，按以下逻辑组织：先给定义：CDN 边缘计算是把计算逻辑从中心化源站下沉到 CDN 边缘节点，在靠近用户的位置处理请求说清价值：降低延迟（200ms → 50ms）、减少回源流量（节省 30%+）、满足数据合规要求列举场景：API 路由、A/B 测试、图片处理、认证鉴权、限流防爬、数据聚合提到平台：Cloudflare Workers / Lambda@Edge / Fastly，能说出各自的适用场景指出挑战：无状态设计、执行时间限制、冷启动、调试困难可能的追问及应对：边缘计算和 Serverless 有什么区别？ Serverless 是一种部署和计费模式，边缘计算是一种架构模式。边缘计算通常采用 Serverless 的方式部署，但 Serverless 不一定运行在边缘。边缘计算适合所有场景吗？ 不适合。需要访问中心数据库的复杂查询、涉及大量数据的批处理、对一致性要求高的事务型操作，仍然应该放在源站或云端处理。边缘节点之间数据如何同步？ 通常通过分布式 KV 存储（如 Cloudflare KV）实现最终一致性，不适合强一致性场景。

面试核心结论CDN 负载均衡的核心策略分为两层：全局调度层（GSLB/DNS）决定用户访问哪个边缘节点，本地均衡层（L4/L7 LB）决定节点内部请求分发到哪台服务器。主要策略包括地理位置路由、就近性路由、轮询、加权轮询、最少连接和一致性哈希。实现高可用的关键在于：健康检查 + 故障自动转移 + 熔断降级 + 多活冗余，缺一不可。追问方向：GSLB 的 DNS 调度流程是怎样的？一致性哈希在 CDN 缓存中为什么重要？Anycast 和 DNS 调度有什么区别？CDN 负载均衡的两层架构理解 CDN 负载均衡，首先要分清两层调度：全局调度（GSLB）：当用户发起请求时，DNS 解析通过 CNAME 指向 CDN 的 GSLB，GSLB 根据用户 IP、节点负载、网络质量等选择最优边缘节点，返回该节点的 IP。这一层决定"用户去哪个机房"。本地负载均衡（SLB）：请求到达边缘节点后，节点内部的负载均衡器（Nginx、HAProxy 等）将请求分发到后端的缓存服务器集群。这一层决定"请求去哪台机器"。面试时很多候选人只讲本地负载均衡，忽略了 GSLB 这一层，这是不够的。CDN 的核心优势——就近接入，正是由 GSLB 实现的。六种核心负载均衡策略地理位置路由（Geo-based Routing）根据用户 IP 所属地域，将请求调度到最近的边缘节点。这是 CDN 最基础也最常用的全局调度策略。实现机制：GSLB 维护一张 IP 地址段到地理位置的映射表（GeoIP 数据库），用户 DNS 请求到达后，查询映射表确定用户所在区域，返回该区域对应节点的 IP。局限性：地理位置近不等于网络延迟低。比如跨运营商访问时，物理距离近但网络绕行严重。因此通常和就近性路由配合使用。就近性路由（Proximity-based Routing）不依赖地理数据，而是通过实际网络测量选择最优节点。测量方式：主动探测：GSLB 定期从各节点向探测点发送 ICMP/TCP 探测，收集 RTT 数据被动测量：分析实际用户请求的响应时间，统计各节点的真实服务质量混合模式：主动探测提供基线数据，被动测量做实时修正实际生产中混合模式最常见。纯主动探测有探测盲区，纯被动测量冷启动阶段没数据。一致性哈希（Consistent Hashing）在 CDN 场景中，一致性哈希的核心价值是提高缓存命中率。为什么重要：如果用轮询策略，同一 URL 的请求可能落在不同缓存服务器上，导致重复回源。用 URL 做一致性哈希，相同 URL 始终路由到同一台服务器，缓存只需存一份。关键参数：虚拟节点数。虚拟节点越多，数据分布越均匀，但管理开销也越大。通常设置 100-200 个虚拟节点。节点变更影响：当节点增减时，一致性哈希只影响相邻虚拟节点上的数据，不会全盘重新分配。相比取模哈希（节点变化时全部重分布），这是巨大优势。# Nginx 一致性哈希配置upstream cdn_cache { hash $request_uri consistent; server 10.0.0.1:8080; server 10.0.0.2:8080; server 10.0.0.3:8080;}加权轮询（Weighted Round Robin）为不同性能的服务器分配不同权重，高性能服务器承载更多请求。upstream cdn_nodes { server 10.0.0.1:8080 weight=5; # 32核 64G 高配 server 10.0.0.2:8080 weight=3; # 16核 32G 中配 server 10.0.0.3:8080 weight=1; # 8核 16G 低配}权重不是一成不变的。成熟的 CDN 系统会根据服务器实时负载（CPU、内存、连接数）动态调整权重，这叫动态权重调整。最少连接（Least Connections）将新请求分发给当前活跃连接数最少的服务器。相比轮询，它适合请求处理时间差异大的场景——轮询只看"分了几个"，最少连接看"还剩多少余力"。upstream cdn_nodes { least_conn; server 10.0.0.1:8080; server 10.0.0.2:8080; server 10.0.0.3:8080;}IP 哈希（IP Hash）用客户端 IP 做哈希，保证同一用户的请求始终落到同一台服务器。主要用于会话保持场景，但在 CDN 中不如 URL 哈希常用，因为 CDN 主要是无状态的内容分发。健康检查：高可用的基础没有可靠的健康检查，负载均衡就是瞎指挥。健康检查分两种：主动健康检查LB 定期向后端发送探测请求，判断服务是否正常：# Nginx Plus 主动健康检查upstream cdn_nodes { zone health 64k; server 10.0.0.1:8080; server 10.0.0.2:8080; health_check interval=5s fails=3 passes=2 uri=/health;}关键参数：interval：探测间隔，正常节点 5-10s，异常节点缩短到 1-2sfails：连续失败几次标记为不健康passes：连续成功几次恢复为健康被动健康检查基于实际业务请求的响应判断，不额外发探测：upstream cdn_nodes { server 10.0.0.1:8080 max_fails=3 fail_timeout=30s; server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;}max_fails=3 fail_timeout=30s 表示 30 秒内失败 3 次，该节点被标记不可用 30 秒。生产实践：两种方式配合使用。主动检查发现硬故障（进程挂了、端口不通），被动检查发现软故障（响应变慢、错误率升高）。高可用架构的关键机制故障自动转移当节点被标记不健康后，负载均衡器自动将流量切到健康节点。关键问题是切换速度：DNS 级别的 GSLB 切换依赖 TTL，即使设置很短的 TTL（如 30s），仍有本地 DNS 缓存问题，实际切换可能需要数分钟Anycast 方式切换更快，因为 BGP 路由变化可在秒级生效本地 SLB 切换最快，通常在 1-2 个探测周期内完成熔断与降级当后端持续异常时，快速失败比慢慢等更好：熔断：错误率超过阈值（如 50%），直接断开，不再向该节点发请求，等一段时间后半开探测降级：返回缓存内容（stale-while-revalidate）、返回简化版本、或者直接拒绝（比超时等待体验更好）# Nginx 熔断配置思路proxy_connect_timeout 2s;proxy_read_timeout 5s;proxy_next_upstream error timeout http_502 http_503;proxy_next_upstream_timeout 10s;proxy_next_upstream_tries 2;proxy_next_upstream 实现了请求级别的自动重试和故障转移。多活与冗余单点永远不可靠。CDN 的高可用需要多层次的冗余：节点级冗余：每个区域至少部署 2 个边缘节点，互为备份服务器级冗余：节点内部至少 2 台缓存服务器网络级冗余：多运营商接入（BGP 多线），避免单运营商故障DNS 级冗余：多组权威 DNS，避免 DNS 服务本身成为单点Anycast 与 DNS 调度的对比这是面试中经常被追问的进阶问题：| 维度 | DNS 调度（GSLB） | Anycast ||------|-------------------|---------|| 切换速度 | 分钟级（受 TTL 和缓存影响） | 秒级（BGP 路由收敛） || 精度 | 基于 IP 库，有偏差 | 基于网络拓扑，更精准 || 运维复杂度 | 相对简单 | 需要 ASN 和 BGP 配置 || 适用场景 | 大多数 CDN | 对延迟敏感、需快速故障转移 || 缓存问题 | 本地 DNS 缓存导致调度不准 | 无此问题 |大型 CDN（Cloudflare、Akamai）通常两种方式结合：Anycast 做全局入口，DNS 调度做精细化区域分配。监控指标与告警负载均衡不是配置完就完事了，需要持续监控：核心指标：P50/P95/P99 响应时间：关注长尾延迟，P99 比 P50 更能反映用户体验下限错误率：5xx 比例超过 0.1% 就需要告警缓存命中率：低于 80% 说明负载均衡策略或缓存策略有问题节点可用性：目标 99.99%（年停机约 52 分钟）告警分级：P1：节点完全不可用 → 立即处理，自动故障转移P2：错误率 > 1% 或 P99 > 5s → 5 分钟内响应P3：缓存命中率下降 > 10% → 工单跟进面试回答要点回答这个问题的正确姿势：先说两层架构：全局调度（GSLB/Anycast）+ 本地均衡（L4/L7），展示你对 CDN 整体架构的理解策略选讲 3-4 个：地理位置路由、一致性哈希、最少连接、加权轮询，每个说清楚适用场景和取舍高可用讲机制链：健康检查 → 故障转移 → 熔断降级 → 多活冗余，形成完整链路举实际例子：比如"我们线上遇到过 DNS 缓存导致 GSLB 切换慢的问题，后来加了 Anycast 做补充"，比纯理论更有说服力提 Anycast：很多人会忽略这个，提了就是加分项

CDN 回源是什么？回源（Origin Pull）是指 CDN 边缘节点没有缓存用户请求的内容时，向源站（Origin Server）请求资源的过程。简单来说：用户请求 → CDN 没有缓存 → CDN 去源站拿 → 缓存一份再返回给用户。回源是 CDN 机制中不可避免的环节，但回源率过高会直接拖慢响应速度、压垮源站、推高成本。面试中考察这个点，核心是看你能不能从"理解机制"到"控制回源"形成完整闭环。回源在什么情况下触发？缓存未命中最常见的回源原因，包含三种典型场景：首次访问：资源从未被任何边缘节点缓存过，冷启动必然回源缓存过期：资源超过 TTL（Time To Live）过期时间，CDN 必须重新验证或拉取缓存被清除：主动刷新（Purge）或被动淘汰（LRU 内存不足）导致缓存消失缓存键不匹配URL 相同但参数不同，CDN 可能将其视为不同资源：https://example.com/api/data?version=1https://example.com/api/data?version=2// 若未配置忽略 version 参数，两次请求各自缓存，回源翻倍生产环境中，UTM 参数、时间戳、随机 token 是导致缓存键膨胀的三大元凶。请求类型或头部触发回源POST/PUT/DELETE：写操作通常不缓存，直接回源携带 Authorization/Cookie：CDN 默认不缓存带鉴权头的响应动态内容：业务规则标记为不可缓存的路径（如 /api/、/user/）回源对系统有什么影响？延迟：从毫秒到秒级的跨越缓存命中：用户 → 边缘节点，通常 < 50ms回源请求：用户 → 边缘节点 → 源站 → 边缘节点 → 用户，延迟 200ms~1s+回源率每升高 10%，P99 延迟可能翻倍。高并发场景下，回源还会引发排队效应，延迟雪崩式恶化。源站压力：回源风暴的风险当热点资源同时过期，多个边缘节点会同时向源站发起请求，这就是回源风暴（Thundering Herd）。极端情况下，10 个边缘节点 × 每秒 1000 次 = 源站瞬间承受 10000 QPS，可能导致源站宕机。成本：回源带宽是真金白银CDN 回源流量通常按带宽计费，价格高于普通 CDN 出流量源站需要更高配置承受回源压力超出套餐配额的回源流量费用更高如何减少回源？六大核心策略策略一：合理设置缓存 TTL不同类型资源设置不同的过期时间：// 静态资源：长 TTL + immutableCache-Control: public, max-age=31536000, immutable// 半静态内容：中等 TTLCache-Control: public, max-age=3600// 动态 API：短 TTL + stale-while-revalidateCache-Control: public, max-age=10, stale-while-revalidate=60stale-while-revalidate 是一个容易被忽视的关键指令：它允许 CDN 在后台异步刷新缓存的同时，先返回过期的旧内容给用户。既保证响应速度，又保证内容最终一致。配合 URL 版本化更新静态资源，彻底避免因内容更新导致的缓存失效：// 版本化文件名，内容变更即更换 URL/app.v1.a1b2c3.js/app.v2.d4e5f6.js策略二：缓存预热（Prefetch）在用户访问前，主动将内容推送到 CDN 节点：# 通过 CDN API 预热 URLcurl -X POST "https://cdn-api.example.com/prefetch" \ -H "Authorization: Bearer <token>" \ -d "{\"urls\": [\"https://example.com/new-page.html\", \"https://example.com/bundle.js\"]}"预热适用场景：新版本发布前预热静态资源大促活动前预热商品页面热门内容预测性预热（基于历史访问模式）策略三：配置缓存键优化忽略无关查询参数，让更多请求命中同一缓存：// 配置忽略 utm_source、timestamp 等参数https://example.com/data?utm_source=wechat&ts=123https://example.com/data?utm_source=weibo&ts=456// 忽略参数后，两个请求命中同一份缓存规范化请求头：统一 Vary 头，避免因 Accept-Encoding 差异产生重复缓存。策略四：多级缓存架构CDN 本身就有多级缓存结构，合理利用可以大幅减少回源：边缘缓存（L1）：离用户最近，容量小，响应最快区域缓存（L2）：覆盖一个地理区域，容量中等中心缓存 / Origin Shield（L3）：所有边缘节点的回源汇聚点Origin Shield 是 AWS CloudFront 的叫法，Akamai 称为 Origin Shielding，阿里云叫集中回源。核心原理：在源站前再加一层缓存，即使所有边缘节点都 miss，也只需一次回源到 Shield 层，避免多节点直接打源站。Akamai 的数据显示，Origin Shield 可以减少 95% 的源站请求。策略五：请求合并（Request Coalescing）当多个用户同时请求同一份未缓存的资源时，CDN 只向源站发一次请求，其余请求排队等待同一份响应。这个机制叫做请求合并或 Request Collapsing。这是解决回源风暴的核心手段。没有请求合并，1000 个并发 miss 请求 = 1000 次回源；有了请求合并，= 1 次回源。策略六：边缘计算将简单逻辑下沉到 CDN 边缘节点执行，避免回源：A/B 测试分流：在边缘节点根据 Cookie 分配实验组URL 重写：边缘节点直接改写 URL，无需回源简单 API 聚合：边缘节点拼接多个缓存片段返回地理定向：根据用户 IP 返回不同区域的缓存内容面试追问与回答追问 1：缓存穿透、缓存击穿、缓存雪崩分别是什么？和回源有什么关系？穿透：请求的数据源站也不存在，每次都回源且永远无法缓存。解决：缓存空值或用 Bloom Filter 拦截击穿：热点 key 过期瞬间，大量请求同时回源。解决：请求合并 + 互斥锁回源雪崩：大批 key 同时过期，回源量暴增。解决：TTL 加随机偏移 + stale-while-revalidate追问 2：如何监控回源率？合理范围是多少？核心指标：回源率 = 回源请求数 / 总请求数，目标 < 5%回源带宽占比 = 回源流量 / 总出流量回源延迟 P99通过 CDN 控制台或日志分析工具（如 ELK）监控，设置回源率 > 10% 的告警阈值。追问 3：CDN 回源和源站宕机如何处理？配置 stale-if-error 指令，源站不可用时返回过期缓存设置源站健康检查，自动切换到备用源站多源站负载均衡 + 故障自动摘除关键业务配置 Origin Shield 作为缓冲层

CDN 账单为什么这么高？一家中型互联网公司，业务量稳定增长，但 CDN 月费从 8 万涨到了 28 万，涨幅远超业务增速。复盘后发现：缓存命中率只有 72%，图片未做格式转换，视频全部用 H.264 编码，没有做任何成本管控。经过一轮系统优化，月费降回了 11 万。CDN 成本优化不是省钱，是花该花的钱。下面从成本构成、六大核心优化策略、监控体系三个层面讲清楚。CDN 成本由哪些部分组成？理解成本结构是优化的前提。CDN 的费用主要来自五个方面：| 费用类型 | 计费方式 | 占比（典型场景） ||---------|---------|--------------|| 流量/带宽 | 按流量（GB）或按带宽峰值（Mbps） | 60%-70% || 请求次数 | 按千次请求计费 | 10%-15% || HTTPS 证书 | 按证书数量或域名数 | 3%-5% || 安全防护（WAF/DDoS） | 按规则数或防护流量 | 5%-10% || 边缘计算/视频处理 | 按调用次数或处理时长 | 5%-10% |流量/带宽是绝对大头，优化重心应该放在这里。计费方式的选择也很关键：流量平稳的业务选按流量计费更划算，有明显峰值波动的（如直播、促销）选按带宽峰值第五计费（95 带宽）更合适。策略一：缓存命中率提升到 95% 以上缓存命中率每提升 1 个百分点，回源流量大约减少 3%-5%。命中率从 72% 提升到 95%，仅此一项就能节省 30% 以上的流量成本。关键配置：# 静态资源：长缓存 + immutableCache-Control: public, max-age=31536000, immutable# API 响应：短缓存，CDN 侧可缓存更久Cache-Control: public, max-age=60, s-maxage=300# 用户敏感数据：禁止缓存Cache-Control: no-store缓存键优化也很容易被忽略。默认缓存键会包含所有查询参数，但 ?utm_source=xxx 这类追踪参数不影响内容，应该忽略：# 忽略不影响内容的查询参数proxy_cache_key "$scheme$request_method$host$uri";资源版本化是避免缓存失效的常用手段。不要用 style.css?v=2，改成 style.v2.css，旧版本自然过期，不需要手动刷新缓存。缓存预热适合内容发布场景。新页面上线前，主动将关键资源推送到边缘节点，避免用户首次访问时回源。大部分 CDN 厂商都提供了预热 API，可以在 CI/CD 发布流程中自动调用。缓存一致性是面试常问的追问点。常见方案有三种：一是 TTL 自然过期（最简单，适合容忍短暂不一致的场景）；二是主动 Purge（适合内容更新后必须立即生效的场景，但频繁 Purge 会降低命中率）；三是版本化 URL（改 URL 不改内容，最推荐）。实际生产中通常组合使用：静态资源用版本化 URL，动态内容用短 TTL + 关键更新时 Purge。策略二：内容压缩和格式转换图片优化：单此一项可减少 50%-70% 流量| 格式 | 适用场景 | 相比 JPEG 节省 ||-----|---------|-------------|| WebP | 照片、复杂图形 | 25%-35% || AVIF | 对兼容性要求不高的场景 | 40%-50% || PNG → WebP | 含透明通道的图 | 60%-70% |实际操作中，用 CDN 的图片处理服务做实时转换是最省事的方案。Cloudflare 的 Polish、阿里云的图片处理、七牛的 imageView2 都支持按请求参数自动转换格式和压缩质量。这种方式不需要改源站图片，CDN 边缘实时转换，用户请求时自动返回最优格式。<!-- 通过 URL 参数请求 WebP 格式 --><img src="https://cdn.example.com/photo.jpg?format=webp&q=80">也可以通过 Accept 请求头自动协商：浏览器发送 Accept: image/webp，CDN 自动返回 WebP 格式，无需改业务代码。文本压缩：Brotli 比 Gzip 再省 20%-30%gzip on;gzip_types text/plain text/css application/json application/javascript;# Brotli 压缩效果更好，主流浏览器已支持brotli on;brotli_types text/plain text/css application/json application/javascript;brotli_comp_level 6;Brotli 在压缩比上优于 Gzip，但压缩速度稍慢。对于静态资源可以预压缩，动态内容用 Gzip 即可。Cloudflare 默认开启 Brotli，阿里云 CDN 需要在控制台手动开启。视频优化：编码格式选择影响巨大H.264 是兼容性最好的选择，但从成本角度看，H.265/HEVC 比 H.264 节省约 50% 的码率，AV1 节省约 60%。如果目标用户主要在移动端，可以优先推送 H.265 版本。自适应码率（ABR）也是必须做的：根据用户带宽动态选择清晰度，避免 4K 视频推给 3G 网络，既浪费流量又卡顿。HLS 和 DASH 协议都原生支持 ABR，配置好码率阶梯即可。策略三：计费方式优化很多人只关注 CDN 的单价，但计费方式选错了，再低的价格也省不了钱。按流量 vs 按带宽峰值：流量平稳、可预测 → 按流量计费有明显高峰（直播、促销、游戏更新）→ 按 95 带宽峰值计费流量波动大但不确定 → 先按流量计费，积累一个月数据再判断预留带宽/流量包： 各厂商都提供预付费流量包，通常比按量付费便宜 20%-40%。适合流量稳定的业务。阿里云的 CDN 流量包、腾讯云的预付费带宽包都是这个思路。跨区域费用差异： 国内流量和海外流量价格差 2-5 倍。如果海外用户不多，不需要开全球加速。只开需要的区域，能省不少钱。一个常见误区是开了"全球加速"却 90% 的流量来自国内，多花了好几倍的钱。主流 CDN 厂商价格对比（国内流量，2026 年参考价）：| 厂商 | 按流量（元/GB） | 按带宽（元/Mbps/天） | 特点 ||-----|-------------|-----------------|-----|| 阿里云 | 0.20-0.24 | 0.96-1.36 | 生态完善，流量包折扣大 || 腾讯云 | 0.20-0.25 | 0.96-1.20 | 免费额度多，适合中小业务 || 七牛云 | 0.18-0.29 | - | 图片处理能力强 || Cloudflare | 免费起步 | Pro $20/月 | 海外节点多，国内速度一般 |策略四：多 CDN 架构单一 CDN 供应商存在两个问题：一是议价空间有限，二是可用性风险集中。多 CDN 不是大公司才需要，日流量超过 10TB 就值得考虑。实现方式：DNS 层面：用 CNAME 指向多个 CDN，做加权轮询。缺点是切换延迟较高（DNS 缓存 TTL）智能调度：根据用户位置、CDN 节点负载、实时成本选择最优路径。DNSPod、NS1 等支持按策略解析按内容类型分配：静态资源走便宜 CDN，动态内容走高性能 CDN，视频走专用 CDN// 简化的 CDN 选择逻辑function selectCDN(contentType, userRegion) { const policy = { 'image': { cdn: 'low-cost-cdn', regions: ['cn-east', 'cn-south'] }, 'video': { cdn: 'video-cdn', regions: ['global'] }, 'api': { cdn: 'high-perf-cdn', regions: ['cn-east'] } }; return policy[contentType]?.cdn || 'default-cdn';}按内容类型分配 CDN 的成本差异示例： 一家视频平台把图片流量切到低成本的通用 CDN（单价低 40%），视频流量留在专用 CDN，整体成本下降约 25%。多 CDN 的难点在于缓存一致性管理和流量调度精细化。面试中如果追问，可以从 DNS 切换的延迟问题、缓存预热策略、流量分配比例调整这几个角度展开。策略五：请求次数优化请求次数费用容易被忽略，但在高并发场景下占比不低。每千次请求 0.01 元，日请求 10 亿次就是每天 1 万元。主要优化手段：资源合并：把多个小文件合并成一个，减少请求数。CSS/JS 打包是基本操作雪碧图：小图标合并为一张大图，用 CSS 定位显示。在 HTTP/1.1 下效果明显，HTTP/2 下收益降低HTTP/2 多路复用：升级到 HTTP/2 后，多个请求可以复用一个连接，但请求次数仍然计费减少无效请求：404 请求也计费，定期清理失效链接和过期资源API 响应合并：多个接口调用合并为一个批量接口，减少 API 请求次数策略六：成本监控与告警不做监控的优化都是盲目的。需要关注的指标：| 指标 | 告警阈值 | 说明 ||-----|---------|-----|| 缓存命中率 | 20% | 短期突增可能是攻击或配置错误 || 带宽峰值/均值比 | > 3:1 | 峰值过高说明可以优化计费方式 || 4xx/5xx 比例 | > 1% | 错误请求也在花钱 |成本归因分析也很重要。用 SQL 分析 CDN 日志，找出流量 Top 10 的 URL，看看是不是某个大文件没做压缩，或者某个接口的缓存 TTL 设置太短。-- 查询流量最大的 URLSELECT url, SUM(bytes) as total_bytes, COUNT(*) as requestsFROM cdn_logsWHERE date >= CURRENT_DATE - INTERVAL 7 DAYGROUP BY urlORDER BY total_bytes DESCLIMIT 10;-- 查询缓存命中率低的 URLSELECT url, COUNT(*) as total, SUM(CASE WHEN cache_status = 'HIT' THEN 1 ELSE 0 END) / COUNT(*) * 100 as hit_rateFROM cdn_logsWHERE date >= CURRENT_DATE - INTERVAL 7 DAYGROUP BY urlHAVING hit_rate < 80ORDER BY hit_rate;优化效果汇总| 优化手段 | 典型节省幅度 | 实施难度 ||---------|-----------|--------|| 缓存命中率提升（72%→95%） | 30%-40% 流量 | 低 || 图片格式转换（JPEG→WebP） | 25%-35% 图片流量 | 低 || 视频编码升级（H.264→H.265） | 40%-50% 视频流量 | 中 || 计费方式调整 | 10%-30% 总成本 | 低 || 多 CDN 架构 | 15%-25% 总成本 | 高 || Brotli 替代 Gzip | 20%-30% 文本流量 | 低 |优化优先级建议：先做缓存命中率和图片优化（投入小、见效快），再做计费方式调整和视频编码升级（需要一定技术投入），最后考虑多 CDN 架构（架构改动大）。面试中回答这个问题，核心要传达三点：一是理解 CDN 成本的结构性差异（流量是大头，优化重心在这里），二是掌握分层优化思路（缓存 → 内容 → 计费 → 架构），三是能给出量化的优化预期（不是笼统的"能省钱"，而是"缓存命中率从 X 提升到 Y 可以节省 Z% 的流量成本"）。追问方向通常涉及缓存一致性如何保证、多 CDN 的流量调度怎么实现、如何平衡成本和性能——这三个问题想清楚，这个话题基本就过了。

直接回答CDN 缓存策略核心就三件事：控制缓存多久（TTL）、区分缓存谁（Cache Key）、决定何时更新（刷新机制）。优化命中率的关键是：减少回源、合理分 TTL、忽略无关参数、预热热门资源。缓存策略拆解TTL 策略——最基础的缓存控制TTL 决定内容在边缘节点的存活时间：静态资源（图片、字体、CSS/JS 带 hash）：设长 TTL，甚至 max-age=31536000, immutable半静态内容（商品页、文章页）：分钟级 TTL，配合软刷新动态接口（用户数据、实时行情）：不缓存或秒级 TTL，走协商缓存（ETag / Last-Modified）Cache-Control: public, max-age=31536000, immutable // 带 hash 的静态资源Cache-Control: public, max-age=300, s-maxage=60 // CDN 缓 60s，浏览器缓 5minCache-Control: no-cache, ETag: "v2-abc" // 协商缓存Cache Key 策略——决定哪些请求共享缓存默认 Cache Key 是完整 URL。问题在于：?utm_source=weibo 和 ?utm_source=zhihu 本是同一资源，却被分成两条缓存，白白回源。优化方式：忽略无关查询参数：过滤 utm_*、timestamp 等不影响内容的参数自定义 Cache Key：加入 Cookie 中的地区码，忽略 PHPSESSIDVary 头：让 CDN 按 Accept-Encoding 区分 gzip/br 版本分层缓存——边缘 → 区域 → 源站请求查找顺序：边缘节点 → 区域节点 → 源站。边缘未命中会回区域，区域未命中才回源。所以优化重点是让请求尽量在边缘命中。命中率优化实战1. 忽略 URL 参数这是命中率低最常见的原因。一条 ?token=xxx 就能让缓存全部失效。阿里云 CDN 实测：忽略无关参数后命中率可从 40% 提升到 90%+。2. 大文件分片回源（Range 回源）用户看视频只看了前 5 分钟，但 CDN 回源拉了整个文件。开启 Range 回源后只拉需要的片段，减少回源流量，也提升字节命中率。3. 缓存预热新版本发布或大促前，主动把热门资源推到各边缘节点。两种方式：API 预热：调用 CDN 控制台接口主动推送模拟请求：用脚本批量请求触发被动缓存4. 版本化发布代替刷新与其发版后全站刷新缓存，不如在文件名里带 hash：app.3f2a1b.js。内容变了 hash 就变，旧缓存自然过期，无需主动刷新。5. 监控命中率指标请求命中率 = 缓存命中请求数 / 总请求数字节命中率 =（边缘响应流量 - 回源流量）/ 边缘响应流量请求命中率 >90% 为健康，70%-90% 需要优化，<70% 必须排查。追问：内容更新后用户还看到旧版本怎么办？三层解法，按优先级：文件名带 hash，一劳永逸（最推荐）URL 刷新，精确清除单条缓存全站刷新，最后手段，会瞬间压高源站追问：缓存命中率突然下降怎么排查？按这个顺序查：看是否有新参数打入了 Cache Key（查访问日志里的 URL 变体）看源站是否返回了 no-store / private 头看 TTL 是否被覆盖缩短看是否有大流量回源（可能是爬虫或攻击绕过缓存）

直接回答CDN 配置 HTTPS 主要有三种方式：自定义证书上传、CDN 免费证书、SNI 多域名证书。HTTPS 回源模式分三档：Flexible（仅客户端加密）、Full（全链路加密但不验证源站证书）、Full Strict（全链路加密且严格验证源站证书），生产环境应选 Full Strict。HTTPS 配置方式自定义证书上传：购买或申请 SSL 证书后，在 CDN 控制台上传 .crt 证书和 .key 私钥。优点是完全可控，支持通配符和 EV 证书；缺点是需手动续期。CDN 免费证书：主流 CDN 支持 Let's Encrypt 等免费证书，自动签发和续期，适合中小站点。Cloudflare 的 Universal SSL 就属此类。SNI 方式：CDN 在同一 IP 上通过 SNI 区分不同域名的证书，客户端握手时携带域名，服务端返回对应证书。现代浏览器均支持。# Cloudflare 启用 Universal SSL 示例curl -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/settings/ssl" \ -H "Authorization: Bearer {api_token}" \ -H "Content-Type: application/json" \ -d '{"value":"strict"}'三种 HTTPS 回源模式这是面试核心，务必理解三者区别：Flexible：用户→CDN 走 HTTPS，CDN→源站走 HTTP。源站无需证书，但回源链路明文传输，存在中间人风险。仅适合测试环境或纯静态内容。Full：全链路 HTTPS，但 CDN 不验证源站证书是否合法（自签名证书也接受）。比 Flexible 安全，但无法防御源站侧的证书伪造攻击。Full Strict：全链路 HTTPS + 严格证书验证，要求源站证书由受信 CA 签发且域名匹配。安全性最高，证书异常会直接拒绝连接。金融、政务等场景必选。关键配置实践强制 HTTPS 跳转和 HSTS 是标配：# Nginx 强制跳转server { listen 80; return 301 https://$host$request_uri;}# HSTS 响应头add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;SSL 协议只保留 TLS 1.2 和 1.3，禁用弱加密套件。启用 OCSP Stapling 减少握手延迟，配置会话缓存复用 SSL 连接：ssl_protocols TLSv1.2 TLSv1.3;ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;ssl_session_cache shared:SSL:10m;ssl_stapling on;ssl_stapling_verify on;常见坑无限重定向循环：CDN 开启强制 HTTPS，源站又把 HTTPS 重定向回 HTTP，形成死循环。解决办法是源站只监听 80 端口或正确识别 CDN 传递的 X-Forwarded-Proto 头。混合内容警告：HTTPS 页面加载了 HTTP 资源，浏览器会拦截。用 CSP 头自动升级：Content-Security-Policy: upgrade-insecure-requests。证书链不完整：只上传了域名证书缺少中间证书，导致客户端无法验证。解决：按域名证书→中间证书的顺序拼接后上传。追问方向SNI 在什么场景下会失效？老旧客户端（IE6/Windows XP）不支持 SNI，CDN 如何兼容？如果源站证书过期，Full Strict 模式下会发生什么？如何做到零停机续期？CDN 开启 HSTS 后源站切换回 HTTP 会有什么后果？

CDN 如何实现视频加速？有哪些关键技术？CDN 视频加速的核心思路：把视频切片、多码率编码、缓存在离用户最近的边缘节点，播放时根据网络状况动态选择码率和分片，从而降低首屏时间、减少卡顿。一、自适应码率（ABR）播放器实时检测带宽和缓冲区水位，动态切换码率档位。主流 ABR 算法分三类：基于缓冲区：缓冲区低选低码率，充足选高码率，实现简单但反应慢基于吞吐量：用近期下载速率预估带宽，选不超过带宽的最高码率，反应快但波动大混合算法：同时参考缓冲区和吞吐量，BOLA 和 MPC 是工业界常用方案追问：ABR 切换时为什么会出现画面模糊再清晰？因为切换发生在分片边界，中间需要等当前分片播完才能请求新码率分片，这段时间画面保持旧码率。二、视频编码优化| 编码格式 | 相比 H.264 体积 | 编码速度 | 兼容性 | 典型场景 ||---------|----------------|---------|--------|---------|| H.264 | 基准 | 快 | 最好 | 通用点播 || H.265 | 小 50% | 慢 3-5x | 较差 | 高清/带宽受限 || AV1 | 小 60% | 极慢 | 有限 | 未来/超高清 |生产中通常生成多码率多分辨率版本（码率阶梯），编码参数重点控制：GOP 大小（关键帧间隔）、maxrate/bufsize（码率上限）、帧率（动态场景 60fps，静态 24fps）。三、流媒体协议：HLS vs DASHHLS（Apple 主导）：m3u8 播放列表 + .ts 分片，生态成熟，iOS 原生支持。DASH（MPEG 标准）：mpd（XML）+ .m4s 分片，跨平台，灵活度更高。两者都能跑在纯 HTTP 上，天然适配 CDN 缓存。CMAF 格式让 HLS 和 DASH 共用同一套 fMP4 分片，只需维护两份 manifest，存储成本减半。追问：直播场景下 HLS 延迟为什么高？如何优化？HLS 延迟 = 分片时长 x 3（编码缓冲 + 播放列表刷新 + 缓冲区预载）。优化方向：缩短分片到 2-4 秒、用 LL-HLS 的部分分片预加载、或改用 WebRTC/FLV 方案。四、CDN 缓存策略分片缓存：每个 .ts/.m4s 独立缓存，命中率高，TTL 可设较长（1-24h）播放列表缓存：.m3u8/.mpd 动态更新，TTL 短（直播 5s，点播 5min）缓存锁：proxy_cache_lock 防止同一分片并发回源击穿缓存智能预加载：播放器预取后续 2-3 个分片和下一码率档位五、传输层优化HTTP/2 多路复用减少连接数、头部压缩降低开销；HTTP/3（QUIC）基于 UDP 减少握手延迟、改善弱网拥塞控制。点播用 HTTP 足够，直播低延迟场景倾向 UDP（WebRTC）。六、播放体验优化首屏慢的典型链路：DNS 解析 → TCP 连接 → TLS 握手 → 请求 m3u8 → 请求分片 → 解码首帧。优化手段：预连接、初始选低码率快速起播、增加关键帧频率（GOP 缩小到 1-2 秒）、预加载首屏分片。拖动进度条时，需要定位到目标时间对应的关键帧所在的分片。关键帧间隔越短，seek 响应越快，但编码效率略降。七、质量监控关键指标：首屏时间、卡顿率、码率切换频率、平均播放码率。播放端通过 waiting/playing 事件采集缓冲数据，定时上报，服务端做聚合告警。追问：卡顿率高但码率切换少，可能是什么原因？ABR 没有及时降码率，可能是吞吐量估算偏高、缓冲区水位阈值设置过高，或者分片缓存未命中导致回源延迟。

CDN 能防住 DDoS 吗？核心机制是什么CDN 确实能防御 DDoS，但靠的不是单点硬扛，而是分布式架构把攻击流量"化整为零"。核心思路：隐藏源站 IP + 全球节点分散流量 + 智能清洗恶意请求。DDoS 防护：流量清洗是关键CDN 防御 DDoS 的核心是流量清洗——在边缘节点识别并过滤恶意流量，只把正常请求回源。清洗分三层：L3/L4 网络层：过滤 SYN Flood、UDP Flood、ICMP Flood 等协议级攻击。边缘节点直接丢弃不符合 TCP/IP 规范的畸形包，对特定攻击源 IP 在骨干网层面封禁L7 应用层：分析 User-Agent、Cookie、TLS 指纹等，用 JS Challenge 或滑块验证判断请求是否来自真人。AI 行为分析会给每个请求打信誉分，低分直接拦截Anycast 架构：攻击流量根据地理位置被吸引到最近的边缘节点，把大规模分布式攻击拆成多个小流量就地处理，不集中到单点限流是清洗的辅助手段：# 单 IP 限流limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;location /api/ { limit_req zone=api burst=20 nodelay;}WAF：应用层攻击的防火墙WAF（Web Application Firewall）防护 SQL 注入、XSS、CSRF、文件包含等 Web 攻击：输入验证：过滤用户输入中的恶意载荷输出编码：对响应内容编码，防止 XSS 执行规则匹配：基于正则或签名库拦截已知攻击模式# 防注入和 XSSif ($args ~* "union.*select.*from") { return 403; }if ($args ~* "<script|javascript:") { return 403; }WAF 部署模式：反向代理（CDN 作为代理入口）、透明代理（旁路拦截）、DNS 模式（通过 DNS 重定向引流）。访问控制：限源、限地、防盗链IP 黑白名单——直接放行或封禁特定 IP 段：allow 192.168.1.0/24;deny all;地理位置限制——仅允许特定国家/地区访问，或屏蔽高风险地区：geo $allowed_country { default no; CN yes;}if ($allowed_country = no) { return 403; }Referer 检查——防盗链，阻止第三方直接引用你的资源：valid_referers none blocked example.com *.example.com;if ($invalid_referer) { return 403; }加密传输与 Token 鉴权HTTPS + HSTS 保证传输层安全。Token 认证防止资源被非法访问——服务端用密钥、路径、时间戳生成签名，CDN 边缘校验签名合法性：import hashlib, timedef generate_token(secret, path, ts): return hashlib.sha256(f"{secret}{path}{ts}".encode()).hexdigest()爬虫防护识别合法爬虫（如 Googlebot）放行，恶意爬虫限流或封禁。方法：User-Agent 分析、行为模式识别、访问频率监控。分层防御才是正确姿势单一机制防不住复杂攻击，生产环境必须分层：用户 → CDN 边缘节点（流量清洗） → WAF（应用层防护） → 源站（深度防御）边缘节点：基础过滤、限流、清洗WAF：应用层攻击拦截源站：最小权限、定期审计、应急响应面试回答时记住：CDN 防御 DDoS 靠分布式 + 智能清洗，不是硬扛；应用安全靠 WAF + 访问控制组合拳；生产环境必须分层，没有银弹。追问：CDN 能防住多大规模的 DDoS？ 看厂商能力。主流高防 CDN 的 Anycast 网络总带宽可达 10Tbps+，远超单机高防的 1Tbps 上限。关键在于 Anycast 架构能把流量分散到全球节点，不是靠一台机器硬抗。

CDN 性能监控的五个核心指标缓存命中率——CDN 监控的第一指标。命中率 = 缓存命中请求数 / 总请求数 × 100%，静态资源目标 95% 以上，整体 90% 以上。命中率骤降往往意味着缓存键配置错误或 TTL 过短，这是面试最爱追问的点。TTFB（首字节时间）——从请求发出到收到第一个字节的耗时，包含 DNS 解析、TCP 连接、TLS 握手和服务器处理。静态内容 P95 应低于 100ms，动态内容低于 500ms。注意：要分开统计命中和未命中的 TTFB，否则平均值会掩盖问题。回源率——回源请求数占总请求的比例，目标低于 10%。回源率高直接导致源站压力大、用户延迟高。面试常见追问：缓存命中率突然从 95% 掉到 60%，你怎么排查？思路：检查是否有大范围缓存失效（批量 purge）、缓存键是否冲突、TTL 是否被改短。错误率——4xx 和 5xx 占总请求比例，4xx 目标低于 0.1%，5xx 低于 0.01%。5xx 飙升通常意味着源站过载或 CDN 节点异常，4xx 激增则可能是配置错误（如回源 URL 改了但 CDN 规则没更新）。带宽与 QPS——带宽监控分边缘带宽和回源带宽，QPS 关注峰值和均值。流量突增需要区分是正常业务高峰还是攻击，结合错误率和延迟一起判断。监控体系怎么搭三层架构：数据采集 → 存储/计算 → 可视化/告警。采集层用 CDN 厂商的日志流（Cloudflare Logs、AWS CloudFront 实时日志）或自建 Nginx 日志，关键字段包括 request_time、upstream_cache_status、upstream_response_time。存储计算层用 Prometheus 做指标聚合，ELK 做日志检索。可视化用 Grafana 搭看板，按地域、ISP、内容类型分维度展示。告警规则要设置三个：TTFB P95 超阈值持续 5 分钟、缓存命中率低于 80% 持续 10 分钟、5xx 错误率超 1% 持续 3 分钟。告警通道走企业 IM + 值班电话，5xx 告警级别必须高于延迟告警。面试追问方向缓存命中率低怎么优化？ 检查缓存键是否包含不必要的动态参数、TTL 是否合理、是否需要分层缓存（parent cache + edge cache）。如何区分 CDN 问题还是源站问题？ 对比命中请求和未命中请求的 TTFB，如果命中请求也慢，问题在 CDN 层；如果只有未命中慢，问题在源站或回源链路。多 CDN 怎么监控？ 统一指标口径，用同一套 Grafana 看板对比各厂商的命中率、延迟和错误率，按地域做流量调度。掌握五个核心指标（命中率、TTFB、回源率、错误率、带宽/QPS）加一套采集-存储-告警的完整方案，面试基本够用。

直接回答CDN 故障排查的核心流程：确认范围 → 检查DNS → 检查网络连通性 → 检查缓存状态 → 检查源站 → 定位修复。第一步，确认故障范围。 问三个问题：是全量用户还是部分地域？是持续报错还是间歇性？是从什么时候开始的？范围判断决定后续排查方向——全局故障看CDN节点和DNS，局部故障看网络链路和缓存。第二步，检查DNS解析。 CDN 依赖 DNS 将用户调度到最近的边缘节点，DNS 出问题一切白搭。用 dig 或 nslookup 确认域名是否正确解析到 CDN CNAME，检查不同地域 DNS 服务器的解析结果是否一致。常见坑：DNS 缓存未更新导致调度到已下线节点。第三步，检查网络连通性。 ping 看延迟，traceroute 或 mtr 看链路丢包，curl -v 看 HTTP 握手各阶段耗时。重点关注 SSL 握手时间——如果证书链不完整或配置错误，握手会失败或变慢。第四步，检查缓存状态。 看响应头里的 X-Cache 字段，HIT 还是 MISS。缓存命中率骤降是最常见的性能劣化原因。排查缓存键配置是否合理、TTL 是否过长导致内容不更新、是否有绕过缓存的请求头。第五步，检查源站。 绕过 CDN 直接访问源站，如果源站也慢，问题在源站不在CDN。看源站负载、响应时间、错误日志。核心工具速查| 场景 | 工具 | 用法 ||------|------|------|| DNS排查 | dig/nslookup | dig @8.8.8.8 example.com || 网络延迟 | ping/mtr | mtr -r -c 10 cdn.example.com || HTTP调试 | curl | curl -w "@format.txt" -o /dev/null -s URL || SSL检查 | openssl | openssl s_client -connect host:443 || 缓存分析 | 日志+响应头 | grep "X-Cache" access.log \| sort \| uniq -c || 日志分析 | ELK Stack | Kibana 看错误率趋势和地域分布 |# curl 计时模板 curl-format.txttime_namelookup: %{time_namelookup}time_connect: %{time_connect}time_starttransfer: %{time_starttransfer}time_total: %{time_total}追问：缓存刷新后用户仍看到旧内容怎么办？先确认刷新是否生效——用 curl -I 检查响应头的 X-Cache 和 Last-Modified。如果刷新成功但用户仍看到旧内容，三个可能：本地浏览器缓存、中间运营商缓存、多CDN节点同步延迟。对应措施：版本化URL（app.js?v=2）、缩短TTL、检查CDN供应商的刷新接口是否覆盖全部节点。追问：如何预防CDN故障？三件事：监控告警（节点可用性、缓存命中率、错误率）、健康检查（定时探测各节点）、容灾预案（多CDN切换、源站冗余、DNS快速切流量）。面试中能讲出"监控+容灾"两条线，基本过关。