一致性就是相互獨立的節(jié)點之間如何達(dá)成一項決議的問題
假設(shè)一個具有 N 個節(jié)點的分布式系統(tǒng)，當(dāng)其滿足以下條件時，我們說這個系統(tǒng)滿足一致性：
全認(rèn)同(aggreement)：所有 N 個幾點都認(rèn)同一個結(jié)果
值合法(validity)：該結(jié)果必須由 N 個節(jié)點中的節(jié)點提出
可結(jié)束(termination)：決議過程在一定時間內(nèi)結(jié)束，不會無休止的進(jìn)行下去
看似很簡單，但實現(xiàn)起來并不輕松，因為面臨著以下幾個問題：
消息傳遞異步無序(asynchronous)：現(xiàn)實網(wǎng)絡(luò)不是一個可靠的信道，存在消息延時，丟失，節(jié)點間消息傳遞做不到同步有序(synchronous)
節(jié)點宕機(fail-stop)：節(jié)點持續(xù)宕機，不會恢復(fù)
節(jié)點宕機恢復(fù)(fail-recover)：節(jié)點宕機一段時間后恢復(fù)，在分布式系統(tǒng)中較為常見
網(wǎng)絡(luò)分化(network partition)：網(wǎng)絡(luò)鏈路出現(xiàn)問題，將 N 個節(jié)點隔離成多個部分
拜占庭將軍問題(byzantine failure)：節(jié)點或宕機或邏輯失敗，甚至不按套路拋出干擾決議的信息
問題
異步環(huán)境(asynchronous) 下，節(jié)點宕機(fail-stop)
異步環(huán)境(asynchronous) 下，節(jié)點宕機恢復(fù)(fail-recover)、網(wǎng)絡(luò)分化(network partition)
2PC 解決單節(jié)點宕機
節(jié)點包括 coordinator 和 participants
在不宕機的情況下可以滿足一致性
在第一階段出了問題，回滾就完事兒了
主要是在第二階段
coordinator 宕機：會有 watchdog 作為監(jiān)聽備份，query 其他的 participants 來確定最終的命令是什么，繼續(xù)執(zhí)行。
participants 宕機：與前面類似
但是，在 Phase2 出現(xiàn)了協(xié)調(diào)者和參與者都掛掉的情景
Coordinator 剛發(fā)出一個請求給其中一個 Participant，此時并沒有發(fā)送給其他的 Participants 并沒有收到消息，此時，前面兩者宕機，備用 Coordinator 并不能通過其他的 Participants 來判斷那個宕機的 Participant 是什么狀態(tài) A.commited B.rollback C.propose 所以一旦其他 participants 的操作與宕機的那個不一致，則會造成數(shù)據(jù)的不一致，所以會造成堵塞
3PC
三階段即 propose、precommit、commit 這三個階段，
其中有 watchdog 和 狀態(tài)記錄(logging) 的應(yīng)用
Phase1：如果 coordinator 未收到 participant(宕機) 的 vote，則中止事務(wù)
Phase2：如果未收到 participant(宕機)，因為已經(jīng)投票了，不然不能進(jìn)入 Phase2，所以繼續(xù) commit，participant 恢復(fù)后自行查看 Log 來決定是否 commit
Phase3：同上
3PC 解決了 2PC 的阻塞(不用搖擺判斷是否 commit 還是 abort)，還增加了宕機恢復(fù)后的處理。
