目錄
CAP
分散式系統中，這三個特性只能滿足其中兩個。
一致性（Consistency）
分散式中一致性又分強一致性和弱一致性，強一致性主濁任何時刻任何節點看到的資料都是一樣的，弱一致性一* * 般實現的是最終一致性。
可用性（Availability）
叢集在任何時間內都正常使用
分割槽容錯性（Partition Tolerance）
某一部分叢集壞掉，另一部分仍能正常工作。
對於二選一模型
- CA模型，在分散式系統中不存在，因為捨棄P，意味著放棄分散式系統。比如單機版本的MySQL，如果MySQL考慮主備或叢集部署時，它必須考慮P
- CP模型，捨棄了可用性，一定會讀取到最新的資料，不會讀取到舊資料。一是因為訊息丟失、延遲過高發生了網路分割槽，就影響使用者的體驗和業務的可用性。例如Etcd，Consul和Hbase
- AP模型，捨棄了一致性，實現了服務的高可用。使用者訪問系統的時候，都能得到響應資料，不會出現響應錯誤，但會讀到舊資料。比如Cassandra 和 DynamoDB。
ACID
一致性強，但是伸縮性差
原子性（Atomicity）
要麼全部完成，要麼全部失敗
一致性（Consistency）
事務開始和完成時，資料必須保持一致的狀態，資料庫的完整性約束沒有被破壞。比如A給B轉賬，不論轉賬事務是否成功，兩者存款的總額不變
隔離性（Isolation）
多個事務併發訪問時，事務之間是隔離的，一個事務不能影響到其他事務的結果 ，不能看到其他事務執行時中間某個時刻的資料。
永續性（Durability）
事務完成後，該事務對資料庫所作的更改便持久地儲存在資料庫中，並不會被回滾
關於二階段提交協議
- 二階段提交。
分成提交請求階段（投票階段）和提交執行階段（完成階段）。
第一個階段，每個參與者投票表決事務是放棄還是提交
第二個階段，事務的每個參與者都執行最終統一的決定
BASE
一致性弱，伸縮性強
基本可用（Basic Availability）
分散式系統出現故障時，允許損失部分可用性，保證核心可用。
軟狀態（Soft-state）
允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分散式儲存中一般一份資料至少會有3個副本，允許不同節點間副本同步的延時就是軟狀態的體現。
最終一致性(（Eventual Consistency）
指所有副本經過一定時間後，最終能達到一致的狀態
ACID：大家在買同一本書的過程中，每個使用者的購買請求都把庫存鎖住，等減完庫存，把鎖釋放，後續的人才能進行購買。於是我們同是時間不可能有多個使用者下單，訂單流程要有排隊的情況，這樣就不能做出效能比較高的系統來
BASE：大家可以同時下單，這個時間不需要真正的去分配庫存，然後系統非同步地處理訂單，而且是批量的處理。因為下單的時候沒有扣減庫存，所以有可能會有超賣的情況。而後臺的系統在處理訂單時，發現庫沒有了，才會告訴使用者你沒有購買成功。
BASE和ACID代表兩種截然相反的設計理念，ACID注重一致性，是傳統關係型資料庫（MySQL）的設計思路，BASE關注高可用，大多數分散式事務適合BASE.