CAP

分布式系統(tǒng)中，這三個特性只能滿足其中兩個。

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

對于二選一模型

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

ACID

一致性強，但是伸縮性差

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

關于二階段提交協(xié)議和TCC

• 二階段提交。

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

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

第二個階段，事務的每個參與者都執(zhí)行最終統(tǒng)一的決定

• TCC

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

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

BASE

一致性弱，伸縮性強

基本可用（Basic Availability）：分布式系統(tǒng)出現(xiàn)故障時，允許損失部分可用性，保證核心可用。

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

最終一致性（（Eventual Consistency）：指所有副本經(jīng)過一定時間后，最終能達到一致的狀態(tài)

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

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

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