深入剖析：DNS与CDN为何只能是AP系统

在讨论分布式系统中的CAP定理时，我们经常能听到一句经典的论断：

DNS、CDN 是典型的 AP 系统。

这句话几乎成了技术圈的口头禅，会背的人很多，但真正理解其背后逻辑的人却未必多。更关键的一点在于：它们并非在A（可用性）和C（一致性）之间主动“选择了AP”，而是从设计之初，就“只能是AP”。

一、核心结论先行

重要
DNS和CDN并非“偏向AP”，而是从诞生的第一天起，就不具备构建成CP（强一致性）系统的现实条件。

这并非工程师的架构风格偏好，而是由业务目标、物理条件与真实的网络环境共同决定的必然结果。

二、从DNS的本质任务说起

抛开所有技术实现细节，DNS的核心职责可以用一句话概括：

在任何时候，尽可能返回一个“能用的”解析结果。

请注意这句话里的关键词：

• 不是“最新的”
• 不是“全局一致的”
• 而是——“能用的”

DNS故障的代价是灾难性的

试想一下，如果DNS服务彻底不可用，会发生什么？

• 所有线上业务服务都将无法通过域名访问。
• CDN、API接口、监控系统、回调服务等依赖域名解析的组件会全部瘫痪。
• 整个互联网的访问链路会在“第一跳”就彻底中断。

提示
DNS是互联网的“地基”，地基的第一优先级从来不是毫米级的精确，而是保证绝不坍塌。

三、面对网络分区，DNS的真实抉择

让我们设想一个极其现实的场景：

• 权威DNS服务器部署在北京。
• 某个省份的运营商网络到北京的链路出现异常，发生中断。
• 但该省份内的本地DNS缓存服务器节点仍能正常工作。

这就是一个典型的网络分区（Partition）。

此时，DNS系统只有两种选择。

选择一：坚持一致性（CP）

• 由于无法与权威服务器通信以确认状态，系统为了保证数据一致性。
• 选择拒绝返回任何解析结果。
• 一切等到网络恢复后再议。

结果会怎样？

• 整个省份的用户将面临“全站无法打开”的窘境。
• 即便旧的IP地址依然能够提供服务，系统也不会将其返回给用户。

警告
对DNS而言，“解析失败”的严重性远高于“解析不准”。

选择二：保证可用性（AP）

• 继续使用本地缓存中已有的解析结果。
• 只要记录的TTL（生存时间）尚未过期，就直接返回给用户。
• 即便这个记录可能已经不是权威服务器上最新的版本。

结果又是怎样？

• 用户请求可能会被导向一个旧的IP地址。
• 但只要该IP对应的服务还在运行，业务就能继续。
• 绝大多数用户对此几乎毫无感知。

历史已经给出了答案：DNS从设计之初，就义无反顾地走上了第二条路。

四、TTL：AP思想的制度化体现

很多人将TTL仅仅视为一个“缓存时间参数”。但从分布式系统的视角看：

重要
TTL是DNS主动承认并管理“不一致性”的制度化设计。

TTL的本质含义是：

• 系统明确允许客户端（递归解析器）在一段规定时间内。
• 使用“可能已经过期”的数据。
• 以此来换取整个系统在庞大、不可靠网络环境下的整体可用性。

如果DNS追求的是强一致性（CP），那么：

• TTL应该被设置为0。
• 每次解析请求都必须回源到权威服务器进行确认。

这样一来，DNS在真实的网络环境下将几乎变得不可用。

五、再看CDN：将AP贯彻到极致

如果说DNS是“倾向于AP”，那么CDN（内容分发网络）则是将 AP原则贯彻到了极致。

CDN的核心目标极其纯粹

让内容尽可能靠近用户，并尽可能快地返回。

这一目标直接导致了几个必然结果：

• 边缘节点遍布全球不同地域、不同运营商网络。
• 节点与节点之间、节点与源站之间的网络质量高度不可控。
• 节点之间的状态同步在延迟和可靠性上都无法得到保证。

六、网络分区下，CDN的生死抉择

假设这样一个场景：

• 内容源站（中心）位于华东地区。
• 华南某省的CDN边缘节点与中心源站的网络连接突然中断。
• 但该省份内部的用户访问这个CDN节点却一切正常。

此时，CDN系统面临的选择同样残酷而现实。

如果CDN选择CP（一致性优先）

• 由于无法确认本地缓存的内容是否为最新版本。
• 节点将停止对外提供所有服务。
• 等待网络恢复、能够回源同步后再恢复。

结果将是：

• 所有热门缓存内容瞬间变得不可访问。
• 用户体验出现断崖式下跌。
• 在内容分发这个核心场景里，这完全是不可接受的。

CDN的真实选择（AP）

• 只要本地有缓存，无论新旧，继续向用户提供服务。
• 接受内容可能不是最新版本的事实。
• 即使回源失败，也不影响利用已有数据服务用户。

提示
对于CDN来说，其价值排序非常清晰：“旧内容”远大于“无内容”。

七、为什么CDN根本不可能做成CP系统？

这不是“不想做”，而是物理上就做不到。原因非常现实：

1. 节点规模巨大：动辄成千上万个边缘节点。
2. 网络环境复杂：跨地域、跨运营商，延迟和丢包是常态。
3. 分区是常态：在如此庞大的网络中，部分节点失联是日常事件，而非异常。
4. 内容体量庞大：缓存的文件通常很大，且更新频率不一。

如果强行在这样一个系统中引入强一致性协议（如分布式共识算法）：

• 协议本身带来的通信、协调成本将远超所分发内容的价值。
• 请求延迟会高到无法忍受。
• 整个系统的复杂度将失控，变得难以维护。

重要
一个追求强一致性的CDN，本质上已经不再是CDN了，它将失去其存在的根本意义。

八、DNS与CDN的共同设计哲学

它们都遵循着同一个底层工程原则：

提示
系统优先保证“整体可用”，单个节点或请求的数据正确性可以容忍延迟，并在之后进行修复或更新。

这也正是为什么在互联网体验中，你有时会发现：

• DNS解析到的IP地址不一定是刚变更的最新IP。
• 通过CDN访问同一资源，在不同地区看到的内容版本可能略有差异。

这并非系统设计的缺陷或Bug，而恰恰是一个正常工作的AP系统的标准表现。

九、将“AP”翻译成工程师的语言

许多人觉得CAP定理很抽象。其实，AP可以翻译成更直白的工程决策：

• 承认网络一定会出问题。
• 接受分区（Partition）一定会发生。
• 那么，就不要假装这些问题不存在，而是设计系统与之共存。

DNS和CDN的设计哲学正是如此：

承认不一致性的必然存在，设法管理和控制不一致性的影响范围与时间，而非天真地试图在复杂网络中彻底消灭它。

十、最终总结

DNS和CDN之所以天然是AP系统，并非因为工程师们更偏爱可用性，而是因为在真实、复杂、不可靠的全球网络环境下，面对其核心的业务使命，它们根本没有第二条路可走。

这种由根本目标驱动的架构选择，为我们设计其他分布式系统提供了深刻的启示。如果你对这类系统设计话题感兴趣，欢迎来云栈社区与更多开发者一同探讨。