CAP理論：一個分佈式系統最多隻能同時滿足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）這三項中的兩項。
Consistency 一致性（涉及重要信息如錢財；分佈式存儲系統必須保證）
從客戶端角度，多進程併發訪問時，更新過的數據在不同進程如何獲取的不同策略，決定了不同的一致性:
1.強一致性:對於關係型數據庫，要求更新過的數據能被後續的訪問都能看到.
2.弱一致性：能容忍後續的部分或者全部訪問不到。
3.最終一致性：經過一段時間後要求能訪問到更新後的數據。
CAP中說，不可能同時滿足的這個一致性指的是強一致性。
Availability 可用性（大型互聯網爲了服務可用，捨棄強一致性，保證最終一致性）
服務一直可用，而且是正常響應時間。
Partition Tolerance分區容錯性(分佈式必須要考慮的問題）
分佈式系統在遇到某節點或網絡故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。就是在網絡中斷的情況下，系統如果還能正常工作。
作爲一個分佈式系統，它和單機系統的最大區別，就在於網絡.
現在假設一種極端情況，N1和N2之間的網絡斷開了:
假設N1和N2之間網絡斷開，由於網絡是斷開的，所以N2中的數據依舊是V0.
這時有用戶向N2發送數據讀取請求，
第一，犧牲數據一致性，保證可用性。響應舊的數據V0給用戶；
第二，犧牲可用性，保證數據一致性。阻塞等待，直到網絡連接恢復，數據更新操作M完成之後，再給用戶響應最新的數據V1。
CA(一致性+可用性）without P（容錯性）
單機的Mysql和Oracle；
分佈式集羣中不存在這種情況，因爲多個節點必定考慮主備同步，也就是網絡。
CP(一致性+容錯性）without A（可用性）
分佈式的數據庫，如Redis，HBase，Zookeeper
任何時刻對ZooKeeper請求能得到一致的數據結果:當master節點網絡故障，會進行選舉機制，選舉時集羣不可用。但是它不能保證每次服務請求的可用性，ZooKeeper可能會丟棄一些請求，消費者程序需要重新請求才能獲得結果。
AP(可用性+容錯性）without C（一致性）
12306買票
購買的時候提示你是有票的（但是可能實際已經沒票了），但是過了一會系統提示你下單失敗，餘票不足。其實捨棄的只是強一致性。退而求其次保證了最終一致性。
Eureka
各個節點平等；有節點掛掉，會立刻換至其他節點，保證服務可用，只不過查到的信息可能不是最新的。在網絡穩定後，當前實例新的註冊信息會被同步到其他節點中。
一旦網絡問題發生，節點之間可能會失去聯繫。爲了保證高可用，需要在用戶訪問時可以馬上得到返回，導致全局數據的不一致性。
分佈式一致性
分佈式事務：指會涉及到操作多個數據庫的事務。
關鍵在於保證在所有節點的數據寫操作，要不全部都執行，要麼全部的都不執行。但是一臺機器在執行本地事務的時候無法知道其他機器中的本地事務的執行結果。所以也就不知道本次事務到底應該commit還是 roolback。
常規的解決辦法就是引入一個“協調者”的組件來統一調度所有分佈式節點的執行。
分佈式事務處理模型：
應用程序（ AP ）、
事務管理器（ TM ）、常見的事務管理器是交易中間件
資源管理器（ RM ）、常見的資源管理器是數據庫
通信資源管理器（ CRM ）常見的通信資源管理器是消息中間件
2PC(二階段提交）
參與者（所有節點RM）將操作成敗通知協調者(事務管理器TM)，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。
第一階段：準備階段(投票階段)
事務協調者(事務管理器)給每個參與者(資源管理器)發送Prepare消息，每個參與者要麼直接返回失敗(如權限驗證失敗)，要麼在本地執行事務，但不提交。
第二階段：提交階段（執行階段）
如果協調者收到了參與者的失敗消息或者超時，直接給每個參與者發送回滾(Rollback)消息；否則，發送提交(Commit)消息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。
存在的問題：
1、同步阻塞問題。執行過程中，所有參與節點都是事務阻塞型的。當參與者佔有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態。
2、單點故障。由於協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那麼所有的參與者還都處於鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉一個協調者，但是無法解決因爲協調者宕機導致的參與者處於阻塞狀態的問題）
3、數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求之後，發生了局部網絡異常或者在發送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之後就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。於是整個分佈式系統便出現了數據部一致性的現象。
4、二階段無法解決的問題：協調者再發出commit消息之後宕機，而唯一接收到這條消息的參與者同時也宕機了。那麼即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。
3PC(三階段提交）
1、引入超時機制。同時在協調者和參與者中都引入超時機制。
2、把準備階段一分爲二，最終：canCommit,preCommit,DoCommit。
解決：1.單點故障問題，2.減少阻塞。
一旦參與者無法及時收到來自協調者的信息之後，會默認執行commit，而不會一直持有事務資源並處於阻塞狀態。
存在問題：一致性問題。
由於網絡原因，協調者發送的abort響應沒有及時被參與者接收到，那麼參與者在等待超時之後執行了commit操作。這樣就和其他接到abort命令並執行回滾的參與者之間存在數據不一致的情況。