面試官在白板上寫的三個字母，不是考題是陷阱

「四十分鐘時，面試官在白板上寫了三個字母：C、A、P。讓你選兩個。你說AP，因為分區會發生。他們點頭。然后他們問出區分資深候選人的問題：'沒有分區時，延遲怎么辦？'」

這是原話。不是CAP本身，是那個追問。如果你的答案是「最終一致性就行」，面試已經結束，只是你還不知道。

CAP的盲區：99%的時間在干什么

CAP起源于2000年Eric Brewer的PODC主題演講猜想，2002年由Gilbert和Lynch證明。核心結論：分布式系統無法同時保證一致性、可用性、分區容錯性。這沒問題。

問題在于 framing。真實生產系統99%的生命周期里沒有分區，CAP對這四九個九的正常運行時間完全沉默。

這就是PACELC要修復的。也是資深面試官真正想挖的東西。

「選兩個」的表述像菜單，其實不是。分區容錯在任何跨機部署的系統里都不是可選項——網絡會斷、包會丟、GC暫停會讓集群其他節點以為你分區了。所以分區時的真實選擇只在C和A之間。這部分CAP是誠實的。

但CAP沒告訴你另外99%的時間發生什么。兩個都標AP的數據庫，正常運作時行為可能天差地別。

同一個數據庫，兩種完全不同的延遲

看Cassandra。健康單數據中心環，一致性級別設為ONE時，返回第一個響應的副本，通常個位數毫秒。設為ALL時，等所有副本，落到幾十毫秒，任何一個慢節點都能拖長尾。

同一個數據庫。同一個白板上的字母。兩種完全不同的延遲與一致性權衡。

Daniel Abadi的PACELC公式給這個命了名：如果發生分區（Partition），在A和C之間選；否則（Else），在L（延遲）和C（一致性）之間選。兩軸四象限：PA/EL、PA/EC、PC/EL、PC/EC。第一個字母是分區行為，第二個是穩態行為。框架就這么簡單。

面試官最愛的三個：矩陣的三個角

DynamoDB（PA/EL）。分區期間可用，寫被接受在有leader選舉的分區任一側。正常運作時，AWS文檔寫明「個位數毫秒」延遲用于最終一致讀，強一致讀額外收費并增加往返開銷。默認就是最終一致——它選了延遲而非一致性。你可以按請求翻旗標拿強一致，付雙倍讀容量和明顯更高延遲。權衡是暴露的。

Spanner（PC/EC）。Google圍繞TrueTime構建，這個API返回小時間區間而非單點時間戳。區間內Spanner會等待（字面意義上的sleep）來保證外部一致性。正常運作時，它選了C而非L。分區時，它拒絕寫直到分區恢復——選了C而非A。

CockroachDB（PC/EL）。分區時像Spanner一樣選C。正常運作時用混合邏輯時鐘和租約，默認提供可序列化隔離，但允許 follower 讀在犧牲一致性的情況下降低延遲。你可以用AS OF SYSTEM TIME讀到幾秒前的快照，顯式用一致性換延遲。

三個數據庫。三種不同的「AP」或「CP」標簽，六種不同的實際行為組合。

為什么這 matters：標簽會騙人

資深面試官追問延遲，是在測試你能不能穿透標簽看機制。CAP是二選一的簡化，PACELC是四選二的展開。生產系統的設計空間比白板上的三個字母大得多。

下次有人問你「選CAP的哪兩個」，先問：分區時還是正常時？