CAP和工程權衡

CAP指出：在網絡分離（Partition，P）環境中，分布式系統無法同時保證強一致性（Consistency，C）和可用性（可用性，A）。如果有P，則必須選擇CP或AP。在沒有劃分的情況下，限制不適用，但會出現其他妥協-主要是延遲（後退）和成本。

實用工程超越了CAP：PACELC至關重要（如果P是選擇C或A；否則-在Latency和Consistency之間選擇），一致性模型，SLA/SLO，yuskeys和業務風險。

1）基本定義（無哲學）

一致性（C）：所有客戶都看到相同的結果「好像」操作是順序執行的（線性可變性/強一致性）。
可用性（A）：對未訪問節點的每個請求都會在合理的時間內完成響應,即使分離也是如此。
分離（P）：節點/區域集群之間的通信丟失或嚴重退化；本質上是大規模的「不可避免的」。
PACELC：在P下，選擇C或A；else（當P不在時）選擇L（低延遲）或C（強一致性）。

2）直觀的選擇圖片

CP（一致性更重要）：在分離時，我們拒絕/阻止一些請求，以免破壞不變量。適用於金錢，交易，余額會計。
AP（可用性更重要）：我們總是回答，但我們允許暫時不一致，然後我們建立沖突（CRDT/默奇規則）。適用於sots-fids、喜歡計數器、腰帶配置文件。
CA（同時為C和A）：只有在沒有P的情況下才有可能-也就是說，只要網絡健康。在實際操作中，「CA」是臨時狀態而不是設計屬性。

3）PACELC： 不要忘記延遲

• 區域之間的高度一致性=洲際法定人數⇒ p95的幾十到數百毫秒。
• 本地閱讀（低L）=較弱的保證（read-my-writes, bounded staleness, eventual）。
• PACELC有助於解釋為什麼「快速而嚴格」地在全球範圍內是罕見的：光線不是即時的，而且法定人數隨著網絡的折疊而增加。

4）一致性模型（快速頻譜）

Linearizable/Strong：好像一個順序。
Serializable：等效於某些串行事務順序（高於記錄級別）。
閱讀您的寫作/Monotonic reads：客戶在自己錄制後讀取新值。
Bounded staleness：讀數不超過N版本/Δ t。
Eventual consistency：隨著時間的流逝，所有副本都收斂了；必須解決沖突。

5）產品和協議中的CP和AP模式（概念上）

CP方法：法定日誌/領導力（Raft/Paxos），嚴格的交易，全球領導者位置，同步復制。價格-在P下拒絕部分請求並增加延遲。
AP方法：多向導/多向導，CRDT，gossip分發，異步復制，沖突解決（LWW，矢量時鐘，域代理函數）。價格是領域規則的暫時性和復雜性。

6）多區域妥協

全球領導者（CP）：簡單的邏輯，但「遙遠」地區支付潛伏期；P-阻止記錄。
本地領導者+asinchron （AP）：寫入速度快,然後復制；沖突的變化需要一個默契。
Geo partitioning：數據「生活」更接近用戶/司法管轄區；跨區域-僅聚合。
禁止在沒有傳奇/CRDT的情況下進行雙重寫作：否則會收到幻影和雙重註銷。

7）工程不變量與業務解決方案

首先，不變性：什麼永遠不能被破壞（雙流量，負余量，鍵的唯一性），什麼是「幸存的」事件（查看計數器，建議）。

• 相應運算的「硬」→ CP不變式。
• 「柔和」不變式→ AP，然後進行捏合。

8）緩解妥協的技術

緩存和CQRS：通過接近緩存/投影（AP）讀取，寫入嚴格的日誌（CP）。
RPO/RTO作為一種折衷語言：可以丟失多少數據（RPO）以及恢復的速度（RTO）。
商定ID和時鐘：單調計時器（Hybrid/TrueTime方法），ULID/Snowflake。
傳奇/TSS：商業補償而不是全球鎖定。
CRDT和域名merge：用於收藏，櫃臺，「最後勝利」。
Bounded staleness： UX和準確性的平衡。

9）可觀察性，SLO和事件管理

潛伏期SLO（p50/p95/p99）分別用於閱讀/記錄和區域。
SLO的可用性，考慮到該地區的操縱者。
Lag復制/沖突：沖突比例，平均解決時間。
P號標誌上的 Alerta：跨區域渠道的時空激增，法定誤差上升。
Degrade計劃：僅讀取模式,本地維護,然後默許,禁用「昂貴」功能。

10）策略選擇支票清單

1.哪些不變量不能被破壞？什麼允許事件發生？
2.是否需要低潛伏率的跨區域記錄？

3.目標的SLO（潛在性/可用性）和成本（egress/replication）是什麼?

4.manual merge還是只允許自動機（CRDT/規則）?

5.網絡故障配置文件是什麼： 頻率、持續時間、爆炸無線電?

6.是否有合法的數據本地化（駐留）?

7.每個數據/操作類型可接受哪種一致性模型?

8.你會如何觀察：瀉湖，沖突，法定人數的狀態？

9.P時系統在做什麼： 阻塞、降級、分流?

10.P後恢復和返回數據的計劃是什麼?

11）典型錯誤

追逐「CA Forever」。首先，P必須提前選擇-最好。
全局多向導沒有默奇規則。沖突正在「吞噬」數據和信任。
強烈的一致性「無處不在」。過多的法定人數超過了p95/p99和預算。
沒有交易/傳奇的雙重寫作。丟失的不變式和幻影。
忽略PACELC。在和平時期，潛伏期受到影響，在暴風雨中，可及性受到影響。
沖突與滯後零遙測。問題僅對用戶可見。

12）快速食譜

付款/余額：具有法定人數的CP存儲；僅通過領導者進行記錄；讀取可以緩存，但是在關鍵的UX中-讀取您的寫作。
內容/炸藥：AP復制+CRDT/商用規則；P-在本地服務，然後抓取。
全球SaaS：通過「tenant/region」進行地理分組；在「家庭」區域（CP）中進行嚴格的操作，通過異步投影（AP）進行報告/搜索。
Real Time信號：Anycast/edge+AP總線；關鍵命令通過確認通道（CP）。
審計/日誌：唯一具有CP保證的真理來源（僅附錄），周圍是緩存和投影。

13）迷你建築基準（口頭）

寫核心（CP）：領導者+法定復制、嚴格不變、服務間效應傳奇。
閱讀平面（AP）：實例化視圖、緩存、搜索索引、異步更新。
Geo路由：用戶進入「家庭」地區；P-本地模式+後續復制。
沖突引擎：CRDT/規則；沖突日誌和人工解決手段。
可觀察性：法定人數，滯後，網絡事件圖。

14）實用延遲數學（簡單估計）

光學≈每1000公裏5毫秒（RTT更大）。洲際法定人數→ p95很容易>150-250毫秒。
任何「全局強」記錄都是昂貴的查詢。如果UX需要<100-150毫秒,請考慮本地write-home+異步後果。

15）分離政策

CP路徑：阻止法定人數以外的記錄；包括僅讀取；給用戶誠實的地位。
AP路徑：本地服務；標記版本；還原時-確定性商業；將沖突提升到解析隊列。

二.結論

CAP不是教條，而是提醒：網絡分離是不可避免的，項目必須提前選擇在風暴中犧牲什麼--可用性或嚴格的連貫性。PACELC在晴朗的天氣中增加了關鍵的延遲軸。結合策略：將CP內核保持在不變量神聖的地方，將AP平面保持在速度和穩定性更重要的地方。設置遙測、降級計劃和默奇過程-系統將保留數據和用戶信任。