CAP

分布式系統中，這三個特性只能滿足其中兩個。

• 一致性（Consistency）：分布式中一致性又分強一致性和弱一致性，強一致性主濁任何時刻任何節點看到的數據都是一樣的，弱一致性一* * 般實現的是最終一致性。
• 可用性（Availability）：集群在任何時間內都正常使用
• 分區容錯性（Partition Tolerance）：某一部分集群壞掉，另一部分仍能正常工作。

對于二選一模型

• CA模型，在分布式系統中不存在，因為舍棄P，意味著放棄分布式系統。比如單機版本的MySQL，如果MySQL考慮主備或集群部署時，它必須考慮P
• CP模型，舍棄了可用性，一定會讀取到最新的數據，不會讀取到舊數據。一是因為消息丟失、延遲過高發生了網絡分區，就影響用戶的體驗和業務的可用性。例如Etcd，Consul和Hbase
• AP模型，舍棄了一致性，實現了服務的高可用。用戶訪問系統的時候，都能得到響應數據，不會出現響應錯誤，但會讀到舊數據。比如Cassandra 和 DynamoDB。

ACID

一致性強，但是伸縮性差

• 原子性（Atomicity）：要么全部完成，要么全部失敗
• 一致性（Consistency）：事務開始和完成時，數據必須保持一致的狀態，數據庫的完整性約束沒有被破壞。比如A給B轉賬，不論轉賬事務是否成功，兩者存款的總額不變
• 隔離性（Isolation）：多個事務并發訪問時，事務之間是隔離的，一個事務不能影響到其他事務的結果 ，不能看到其他事務運行時中間某個時刻的數據。
• 持久性（Durability）：事務完成后，該事務對數據庫所作的更改便持久地保存在數據庫中，并不會被回滾

關于二階段提交協議和TCC

• 二階段提交。

分成提交請求階段（投票階段）和提交執行階段（完成階段）。

第一個階段，每個參與者投票表決事務是放棄還是提交

第二個階段，事務的每個參與者都執行最終統一的決定

• TCC

Tty（預留）、Confirm（確認），Cancel（撤銷）

核心思想是針對每一個操作都要注冊一個與基對應的確認操作和補償操作（撤銷操作）

BASE

一致性弱，伸縮性強

基本可用（Basic Availability）：分布式系統出現故障時，允許損失部分可用性，保證核心可用。

軟狀態（Soft-state）：允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分布式存儲中一般一份數據至少會有3個副本，允許不同節點間副本同步的延時就是軟狀態的體現。

最終一致性（（Eventual Consistency）：指所有副本經過一定時間后，最終能達到一致的狀態

ACID：大家在買同一本書的過程中，每個用戶的購買請求都把庫存鎖住，等減完庫存，把鎖釋放，后續的人才能進行購買。于是我們同是時間不可能有多個用戶下單，訂單流程要有排隊的情況，這樣就不能做出性能比較高的系統來

BASE：大家可以同時下單，這個時間不需要真正的去分配庫存，然后系統異步地處理訂單，而且是批量的處理。因為下單的時候沒有扣減庫存，所以有可能會有超賣的情況。而后臺的系統在處理訂單時，發現庫沒有了，才會告訴用戶你沒有購買成功。

BASE和ACID代表兩種截然相反的設計理念，ACID注重一致性，是傳統關系型數據庫（MySQL）的設計思路，BASE關注高可用，大多數分布式事務適合BASE.
編輯：hfy