CAP

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

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

對于二選一模型

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

ACID

一致性強(qiáng)，但是伸縮性差

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

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

• 二階段提交。

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

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

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

• TCC

Tty（預(yù)留）、Confirm（確認(rèn)），Cancel（撤銷）

核心思想是針對每一個操作都要注冊一個與基對應(yīng)的確認(rèn)操作和補(bǔ)償操作（撤銷操作）

BASE

一致性弱，伸縮性強(qiáng)

基本可用（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)過一定時間后，最終能達(dá)到一致的狀態(tài)

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

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

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