1.CAP理論
C:一致性（Consistency） A:可用性（Availability）和分區容錯性（Partition tolerance）。在一個分佈式系統裏面不可能同時滿足CAP這三個基本需求，最多隻能同時滿足其中兩項（在現在分佈式系統中P是都會滿足）。
一致性：是指數據在多個副本之間是否能夠保持一致性。在一致性的需求下，當一個系統在數據一致的狀態下執行更新操作後，應該保持數據任然處於一致的狀態。即針對一個數據項的更新操作執行成功後，所有的用戶都可以讀取到其最新的值，那麼這樣的系統就被認爲具有強一致性。反之若用戶讀到了舊數據（髒讀），則爲分佈式數據不一致情況。
可用性：可用性是指系統提供的服務必須一直處於可用的狀態，對於用戶的每一個操作請求總是能夠在有限的時間內返回結果。
分區容錯性：分佈式在遇到任何網絡分區故障的時候，任然需要能夠保證對外提供一致性和可用性的服務。在分佈式系統中，不同節點分佈在不同的子網絡中，由於一些特殊的原因導致這些子網絡之間出現網絡不連通的狀況，但子網絡的內部網絡是正常的，從而導致整個系統的網絡環境被切分成了若干個孤立的區域。
放棄CAP定理
放棄P：最簡單的做法是將所有的服務在一個節點上
放棄A：即某個節點發生故障，則程序不可用
放棄C：放棄一致性是指放棄強一直性，保留最終一致性，數據最終會達到一個一致狀態，但是在中間可能出現不一致的情況。
2.BASE理論
基本可用（Basically Available）、Soft state（軟狀態）、Eventually consistent（最終一致性）
基本可用：值分佈式系統發生故障的時候，允許損失部分可用性。
① 響應時間上的損失②功能上損失 例如降級操作
軟狀態：即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時
最終一致性：最終一致性是指系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。
最終一致性的5個變種
因果一致性：進程A更新通知進程B，那麼進程B對該數據的訪問能夠獲取到進程A更新後的值，B進程更新要基於更新後的值。
讀已之所寫：進程A更新數據之後，進程A讀取的最新值，不能是舊值
會話一致性：系統保證在同一個有效會話中實現“讀已之所寫”的一致性。
單調讀一致性：一個進程從系統中讀取一個值後，那麼系統對進程後續的任何數據訪問不應該返回更舊的值。
單調寫一致性：系統保證同一個進程的寫操作被順序執行。
3.分佈式一致協議
2PC提交：二階段提交，顧名思義二階段提交是將事務的提交過程分成了兩個階段來處理。
階段一：提交事務請求
1.事務詢問
協調者向所有的參與者發送事務內容，詢問是否可以執行事務提交操作，並開始等待各參與者的響應。
2.執行事務
各參與者節點執行事務操作，並將Undo和Redo信息記入事務日誌中。
3.參與者向協調者反饋事務詢問的響應。
如果參與者成功執行了實務操作，那麼就反饋Yes，表示事務可以執行，否則返回No。
階段二：執行事務提交
假如協調者從所有的參與者獲得反饋都是Yes響應，那麼就會執行事務提交。
1.發送提交請求
協調者向參與者節點發出Commit請求
2.事務提交
參與者接收到Commit請求後，會執行事務提交操作
3.反饋事務結果
4.完成事務
協調者接收到參與者反饋的Ack信息後，完成事務。
中斷事務
假如有一個參與者相協調者反饋了No響應，或者在等待超時之後，協調者無法接收到所有參與者的反饋響應，那麼就會中斷事務。
1.發送回滾請求
協調者向所有參與者節點發出Rollback請求。
2.事務回滾
利用Undo信息來執行事務回滾操作
3.反饋事務回滾結果
4.中斷事務
協調者接收到所有參與者反饋的Ack消息後，完成事務中斷。
優點：原理簡單，實現方便
缺點：同步阻塞、單點問題、數據不一致、太過保守
同步阻塞：在二階段提交的執行過程中，所有參與該事務操作的邏輯都處於阻塞狀態，也就是說，各個參與者在等待其他參與者響應的過程中，將無法進行其他任何操作。
單點問題：一旦協調者出現問題那麼整個階段提交將無法運轉，在階段二中出現故障（即階段一完成後階段二開始之前），那麼其他參與者將會一直處於鎖定事務資源狀態，而無法繼續完成事務操作。
數據不一致問題：在階段二，執行事務提交之後，發生網絡故障或者協調者崩潰，導致只有部分參與者接收到Commit請求。這部分收到Commit請求的參與者就會進行事務提交，而其他沒有收到Commit請求參與者則無法進行事務提交。於是整個系統出現了數據不一致性問題。
太過保守：在階段一事務提交詢問過程中，參與者發生故障導致協調者無法獲取所有參與者響應信息的話，協調者只能依靠自身的超時機制來判斷是否中斷事務。即沒有完善的容錯機制，任意一個節點的失敗都會導致整個事務的失敗。
3PC提交
3PC提交是2PC提交的改進版，將二階段“提交事務請求”一分爲二，形成了CanCommit、PreCommit和do Commit三個階段組成的事務處理協議。
階段一：CanCommit
1.事務詢問
協調者向所有的參與者發送一個包含事務內容的canCommit請求，詢問是否可以執行事務提交操作，並等待響應。
2.各參與者向協調者反饋事務詢問的響應。
可以進行事務提交，反饋Yes狀態，進入預備狀態，否則返回No
階段二：PreCommit
協調者根據參與者的反饋來決定是否可以進行事務的PreCommit操作，正常情況下，包含兩種可能。
1.執行事務預提交
如果參與者響應都是Yes，就會執行預提交。
1.協調者發送預提交請求
協調者向所有參與者發送PreCommit請求，並進入Prepared階段
2.事務預提交
參與者接受到PreCommit請求後，會執行日誌操作，並將Undo和Redo信息記錄到日誌信息中去
3.參與者向協調者反饋事務執行結果
2.中斷事務
參與者反饋No，或者在等待超時之後，協調者無法接收到所有參與者的反饋響應。
1.中斷請求
協調者向參與者發送abort請求
2.中斷事務
無論是收到來自協調者的abort請求還是參與者等待協調者請求過程中出現超時等待，參與者都會中斷事務。
階段三：doCommit
該階段進行真正的事務提交，會存在兩種情況。
1、執行事務提交
參與者在階段二反饋都爲Yes
1.發送提交請求。
協調者向參與者發送doCommit請求，自身從預提交狀態轉換到提交狀態
2.事務提交
3.參與者向協調者返回結果
4.完成事務提交
2、中斷事務
協調者接收到了參與者反饋的No響應，或者在等待超時之後，協調者無法就到到所有參與者的反饋響應。
1.發送中斷請求
2.事務回滾
3.反饋事務回滾結果
4，事務中斷
需要注意：一但進入階段三，可能會存在以下兩種故障
1.協調者出現問題
2.協調者與參與者之間出現網絡故障
無論哪種情況，最終都會導致參與者無法及時收到來自協調者的doCommit或abort請求，參與者都會在等待超時之後，進行進行事務提交。
優點：降低了參與者的阻塞範圍，並且能夠在出現單點故障後繼續達成一致。
缺點：參與者接收到preCommit請求後若協調者和參與者出現網絡故障，參與者會進行事務提交，從而導致數據不一致。