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

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

CAP的盲區(qū)：99%的時間在干什么

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

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

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

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

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

同一個數(shù)據(jù)庫，兩種完全不同的延遲

看Cassandra。健康單數(shù)據(jù)中心環(huán)，一致性級別設(shè)為ONE時，返回第一個響應(yīng)的副本，通常個位數(shù)毫秒。設(shè)為ALL時，等所有副本，落到幾十毫秒，任何一個慢節(jié)點都能拖長尾。

同一個數(shù)據(jù)庫。同一個白板上的字母。兩種完全不同的延遲與一致性權(quán)衡。

Daniel Abadi的PACELC公式給這個命了名：如果發(fā)生分區(qū)（Partition），在A和C之間選；否則（Else），在L（延遲）和C（一致性）之間選。兩軸四象限：PA/EL、PA/EC、PC/EL、PC/EC。第一個字母是分區(qū)行為，第二個是穩(wěn)態(tài)行為�？蚣芫瓦@么簡單。

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

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

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

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

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

為什么這 matters：標簽會騙人

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

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