1. CAP 理論
任何分佈式架構設計的系統，只能同時滿足 CAP 中的任意兩種，無法同時三種並存。
CAP（Consistency、Availability、Partition tolerance） 是三個單詞的縮寫，分別代表一致性，可用性，分區容錯性。
這個理論到目前爲止都適用於分佈式架構系統。
1.1 Consistency 一致性
我們知道ACID中事務的一致性是指事務的執行不能破壞數據庫數據的完整性和一致性，一個事務在執行前後，數據庫都必須處於一致性狀態。
也就是說，事務的執行結果必須是使數據庫從一個一致性狀態轉變到另一個一致性狀態。
舉個例子：
A 轉賬 B ，A 扣款一百，B增加一百，這個是業務層級的一致性，連個業務都執行，才能保證最終一致性狀態。
這種從剛開始的不變的狀態，轉變爲另一種最終一致的狀態，就是一致性。
分佈式環境中的一致性是指數據在多個副本之間是否能夠保持一致。這點應該不難理解，分佈式集羣架構中，有可能服務節點是多個，
這個時候我們就要考慮多個服務的情況下，讀取的數據是否都能夠一致，或者數據庫集羣中的數據是否都能夠保證一致。
- 強一致性
要求所有系統中的數據必須一致，不管誰先執行操作，都要等到其他系統數據更新完成才能繼續執行下一步。
這點就會對性能有一部分影響，因爲要確保所有節點的完全一致。
數據庫爲例，單庫的數據肯定是一致的。多庫情況下，其他節點的數據必須等到日誌更新所有數據庫完全後才能讀取，這樣纔會保證數據的一致性。
- 弱一致性 & 最終一致性
弱一致指數據更新後，不會立即要求所有的節點必須先同步，允許在一定時間後達到同步，這裏面還有一種情況就是可能數據同步會失敗，怎麼辦？
重試機制，失敗了就再次嘗試，直到最終達到一致性。
1.2 Availability 可用性
用戶訪問的服務會處在一種一直可用的集羣狀態，也就是服務高可用。能夠保證一個請求在規定的有限時間返回結果。這裏面還要考慮到服務
熔斷、異常返回、服務降級（容錯性）。這些都是微服務裏面的重要概念。
1.3 Partition tolerance 分區容錯性
容錯性,那就是網絡節點之間無法通信的情況下，節點被隔離，產生了網絡分區， 整個系統仍然是可以工作的.
隨着網絡節點出現問題，產生了分區, 這時候其他節點和出錯節點的數據必然會不一致，這時候就要面臨選擇，
是選擇停掉所有的服務，等網絡節點修復後恢復數據，以此來保證一致性（PC）,
還是選擇繼續提供服務，放棄強一致性的要求，以此來保證整體的可用性（PA）。
2 BASE 理論
eBay的架構師Dan Pritchett源於對大規模分佈式系統的實踐總結，在ACM上發表文章提出BASE理論，BASE理論是對CAP理論的延伸，
核心思想是即使無法做到強一致性（Strong Consistency，CAP的一致性就是強一致性），但應用可以採用適合的方式達到最終一致性
（Eventual Consitency）
BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的縮寫。
BASE理論是對CAP中一致性和可用性權衡的結果，是對大規模互聯網系統分佈式實踐的總結。
BASE理論的核心思想是：即使無法做到強一致性，可以通過一些軟狀態和最終一致性的方式，來儘量達到一致性的要求。
2.1 基本可用
指分佈式系統在出現故障的時候，允許損失部分可用性，保證核心可用。那些情況屬於這種基本可用呢？
-
損失部分響應時間換取：
如果一個系統原本應該 10ms 內響應，但是現在可以允許出錯後重試，可以規定重試N次，可能導致的結果就是時間變爲 10*N，
或者通過網關轉向可用的服務，這種情況比較樂觀，可能不需要N次。 -
損失部分非核心繫統功能：
正常的，我們訪問一個網站服務會返回我們想要的結果，但是如果後臺服務發生了雪崩或者服務降級，我們也會有降級頁面返回的處理結果，
當然對於客戶可能不知道後臺發生了什麼，只是被引導到了降級頁面並看到了立即返回結果，雖然結果不是我們想要的，但是保證了
基本響應。
2.2 軟狀態
軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分佈式存儲中一般一份數據至少會有三個副本，允許不同節點間副本同步的延時就是軟狀態的體現。
mysql replication的異步複製也是一種體現。
2.3 最終一致性
最終一致性：各個節點的數據不一致，可以通過一系列的措施來進行更新補償，最終達到一致性的要求。這個過程就是最終一致性。
強調的是要求最終一致，不需要實時保證系統數據的強一致。
求關注
程序領域
程序領域（id：think-holy）
作者：holy