分散式系統中的CAP、ACID、BASE概念
目錄
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.
