分散式概覽-ACID-CAP-2PC-3PC

ACID是一個事務的四個特徵：

A：Atomic，all or nothing。

C：Consistency，比如A給B轉100塊，需要滿足在動作之前和之後，錢總數不變。即前後一致。

I：Isolation，線程之間獨立。

D：Durability，可持久化。

CAP是資料庫的一個理論，CAP三個原則不可能同時滿足：

C：Consistency，多台機器的數據一致性。

A：Availability，服務可用性，比如你用一個分散式事務從主同步數據到從，這時候服務不可用。

P：Partition-tolerance，分區容忍性，如果多台機器間，產生了分區，比如網路不通，服務是否可容忍。 等同於，【如果多台伺服器有相同的數據，對於分區是可以容忍的】。

CA：單伺服器。

CP：多伺服器，數據強行同步，比如2PC，導致服務短時間不可用。

AP：多伺服器，數據最終一致，比如非同步消息，導致主掛了後，從可能沒有完整數據。

業界方案：

由於每台機器都可能掛，所以排除CA，即數據需要備多份，P必須滿足。從上面可以看出，CP或者AP都有明顯缺點，所以選擇一個折衷的方案：2f+1台伺服器，如果1是主，同步到f台備後就告訴請求方，已經成功。在可用性與一致性方面折衷。

如果備掛了，不用管，直到它自己恢復。

如果主掛了，用Raft等選舉演算法，選舉出新的主。選舉過程中，服務不可用，大概幾百ms。

2PC是分散式事務中的二階段提交：

2pc：2 phase commit。分散式的強一致性。

應用場景：A收到請求，需要從B轉100塊錢給C，他們都在不同的服務上。

類似場景，結婚是事務，神父是協調者，新郎和新娘是參與者：

神父問新娘：你願意嫁給他嗎？新娘說願意。(phase1: request & reply)

神父問新郎：你願意嫁給她嗎？新郎說願意。(phase1: request & reply)

神父對新娘說：那你戴上戒指就算結婚了，新娘戴上了，並回復說戴好了。（phase2: commit & ack）

神父對新郎說：那你戴上戒指就算結婚了，新郎戴上了，並回復說戴好了。（phase2: commit & ack）

對於第一階段，有任意一方失敗，終止結婚。

對與第二階段，

如果神父掛了，用備用的神父頂上。這段時間新郎新娘一直等待。

如果新郎掛了，新郎復活後，可以詢問新郎她是否戴上了戒指，確定整個婚禮狀態。

如果神父在對新郎說完後，自己掛了，然後新郎也掛了。用備用的神父頂上，但是不知道新郎的狀態，不確定新郎是否戴上了戒指，【系統狀態不確定】

3pc：

在2pc中間插入了準備階段，【確定整個系統的狀態】，用來解決2pc，協調者和參與者同時掛掉的問題。

加入了超時機制，協調者超時默認回滾，參與者超時默認成功。