CAP 与 PACELC
CAP THEOREM & PACELC // 网断了，你保哪个
> 分布式系统最著名的一句判决：网络分区发生时，一致性与可用性二选一。它常被讹传成“三选二”的菜单，但真实的含义更锋利——分区不是选项而是宿命（网络一定会断），CAP 真正说的是：断网那一刻，你要么拒绝服务保数据对，要么继续服务忍数据错。PACELC 再补一刀：就算网不断，延迟与一致性也得二选一——这台天平从不收工。
Principle — 原理与来源
三个字母的严格含义：① C（一致性）——线性一致性：任何读都返回最新写，所有节点看到同一世界（不是“最终一致”那种弱 C）；② A（可用性）——每个非故障节点对每个请求都必然在有限时间内返回非错响应（不允许超时/拒绝）；③ P（分区容错）——网络可以丢消息、延迟任意久，系统仍要按上述承诺运转。注意 C 和 A 的定义都极苛刻——这是 2002 年证明成立的前提，放松任何一点（“基本可用”“最终一致”），“不可能三角”就有松口。
为什么分区时 C/A 必须二选一（两节点证明直觉版）：节点 N1、N2 之间网线断了。客户端向 N1 写 x=1，向 N2 读 x。N2 收不到 N1 的消息——它要么等待/拒绝（保 C 弃 A），要么返回旧值（保 A 弃 C）。没有第三条路：N2 不知道自己缺的那条消息存不存在。这不是工程缺陷，是信息论意义上的不可能。
谱系：1999/2000，Eric Brewer（加州伯克利教授、Inktomi 创始人）在 PODC 研讨会提出直觉性猜想（“WEB 服务规模下的权衡”）；2002，MIT 的 Seth Gilbert 与 Nancy Lynch 给出形式化证明，猜想升格定理；2012，Brewer 发表《CAP 十二年后》自我修正：强调“三选二”是误导——分区是罕见事件，系统应该在“分区时”与“正常运行时”采取不同策略（分区时弃 A 保 C 或反之，恢复后补偿）。同年 Daniel Abadi 提出 PACELC：把“正常运行时的延迟 vs 一致性”补进权衡——PA/EL（如 Dynamo 牺牲延迟换可用）、PC/EC（如 BigTable/HBase 牺牲可用保一致），天平全天候在线。
Apply — 用在哪里
Simulate — 分区沙盘 × PACELC 选型器
Personal Takeaways — 个人启示 · 03
约束先于方案
CAP 的价值不是告诉你“选哪个”，是让你承认权衡存在：一切“既要又要还要”的分布式方案，要么在偷偷放弃某一项，要么在等一次分区教会它做人。先写下你愿意牺牲什么，再画架构图——反过来的图，都是欠费停机的预告。
分时段下注，而不是终身承诺
Brewer 2012 修正的深意：分区是事件不是状态——系统可以在 99.9% 的正常时间里高可用 + 强一致（用延迟换），只在分区窗口内切换到预设的牺牲模式。好的架构不是选边站，是写好切换剧本：什么时候弃、弃多久、怎么补。
天平从不收工（PACELC）
CAP 只管断网那一会儿，PACELC 提醒你：平时的“快”与“准”也在同一个天平上——每个同步写都在花延迟买一致性，每个异步刷都在花一致性买延迟。看懂这一点，你读任何数据库的默认配置，读到的都是它的价值观。