站客

在讨论 CAP 定理时，经常能听到一句话：

DNS、CDN 是典型的 AP 系统。

这句话很多人会背，但真正理解的人并不多。
更关键的是：它们并不是“选择了 AP”，而是“只能是 AP”。

一、先明确结论

Important

DNS 和 CDN 不是“偏向 AP”，而是从第一天开始，就不具备做 CP 系统的现实条件。

这不是架构风格问题，而是业务目标 + 物理条件 + 网络现实共同决定的。

二、先看 DNS 在“干什么”

抛开实现细节，DNS 的核心职责只有一句话：

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

注意这里的关键词：

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

DNS 的失败成本极高

如果 DNS 不可用，会发生什么？

业务服务全部不可访问
CDN、API、监控、回调全部瘫痪
整个互联网链路断在“第一跳”
Note

DNS 是互联网的“地基”，
地基的第一优先级不是精确，而是不塌。

三、网络分区下，DNS 面临的真实选择

假设一个非常现实的场景：

权威 DNS 在北京
某省运营商到北京的链路异常
省内缓存节点还能正常工作

这就是典型的网络分区。

此时 DNS 只有两种选择。

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

无法确认权威状态
拒绝返回解析结果
等网络恢复再说

结果是什么？

整个省的用户“全站打不开”
即使旧 IP 还能用，也不给返回
Warning

对 DNS 来说，
“解析失败”比“解析不准”严重得多。

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

继续使用缓存结果
TTL 未过期就直接返回
即使记录不是最新的

结果是：

可能打到旧 IP
但业务还能跑
用户几乎无感知

DNS 从诞生那天起，就已经给出了答案。

四、TTL：AP 的制度化体现

很多人把 TTL 当成一个“缓存参数”，但从分布式角度看：

Important

TTL 是 DNS 主动承认“不一致”的制度化设计。

TTL 的含义，本质是：

我允许你在一段时间内
使用“可能已经过期”的数据
换取系统整体的可用性

如果 DNS 追求强一致：

TTL = 0
每次解析都回权威确认

那 DNS 在现实网络环境下几乎不可用。

五、再看 CDN：AP 更加彻底

如果说 DNS 是“偏 AP”，那 CDN 是 AP 到极致。

CDN 的核心目标非常直接

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

这直接带来几个必然结果：

节点分布在不同地域、不同运营商
节点之间网络质量不可控
节点之间状态同步不可靠

六、CDN 在网络分区下会发生什么

假设：

内容中心在华东
华南某省节点与中心失联
但省内用户访问正常

这时 CDN 面临的选择非常现实。

如果 CDN 选择 CP

无法确认内容是否最新
停止对外服务
等回源、等同步

结果：

热内容全部不可用
用户体验断崖式下降

这在内容分发场景中是不可接受的。

CDN 的真实选择（AP）

只要本地有缓存，就继续服务
内容可能不是最新版本
回源失败不影响已有数据
Note

对 CDN 来说：
“旧内容” ≫ “无内容”。

七、为什么 CDN 根本没法做 CP

这不是“不想”，而是做不到。

原因很现实：

节点规模巨大（成千上万）
跨地域、跨运营商
网络分区是常态而不是异常
内容本身大、更新频率不统一

如果强行引入一致性协议：

协议成本远超内容价值
延迟不可接受
系统复杂度失控
Important

CDN 如果做 CP，
就不再是 CDN 了。

八、DNS / CDN 的一个共同特征

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

Tip

系统优先保证“整体可用”，单点正确性可以延后修复。

这也是为什么你会看到：

DNS 返回的 IP 不一定是最新的
CDN 不同地区内容不一致

这不是缺陷，而是AP 系统的正常表现。

九、把“AP”翻译成工程语言

很多人把 AP 理解成一句抽象口号，其实可以翻译得更直白一点：

网络一定会出问题
分区一定会发生
那就不要假装它不存在

DNS 和 CDN 的设计哲学是：

承认不一致，管理不一致，而不是消灭不一致。

十、总结

DNS 和 CDN 之所以天然是 AP 系统，不是因为工程师偏好可用性，而是因为在真实网络环境下，它们没有第二条路。

为什么DNS和CDN天然是 AP 系统？