本課時(shí)我們來(lái)討論兩階段提交和三階段提交協(xié)議的過(guò)程以及應(yīng)用。

在分布式系統(tǒng)中，各個(gè)節(jié)點(diǎn)之間在物理上相互獨(dú)立，通過(guò)網(wǎng)絡(luò)進(jìn)行溝通和協(xié)調(diào)。在關(guān)系型數(shù)據(jù)庫(kù)中，由于存在事務(wù)機(jī)制，可以保證每個(gè)獨(dú)立節(jié)點(diǎn)上的數(shù)據(jù)操作滿足 ACID。但是，相互獨(dú)立的節(jié)點(diǎn)之間無(wú)法準(zhǔn)確的知道其他節(jié)點(diǎn)中的事務(wù)執(zhí)行情況，所以在分布式的場(chǎng)景下，如果不添加額外的機(jī)制，多個(gè)節(jié)點(diǎn)之間理論上無(wú)法達(dá)到一致的狀態(tài)。

在分布式事務(wù)中，兩階段和三階段提交是經(jīng)典的一致性算法，那么兩階段和三階段提交的具體流程是怎樣的，三階段提交又是如何改進(jìn)的呢？

協(xié)調(diào)者統(tǒng)一調(diào)度

在分布式事務(wù)的定義中，如果想讓分布式部署的多臺(tái)機(jī)器中的數(shù)據(jù)保持一致性，那么就要保證在所有節(jié)點(diǎn)的數(shù)據(jù)寫操作，要么全部都執(zhí)行，要么全部都不執(zhí)行。但是，一臺(tái)機(jī)器在執(zhí)行本地事務(wù)的時(shí)候無(wú)法知道其他機(jī)器中本地事務(wù)的執(zhí)行結(jié)果，節(jié)點(diǎn)并不知道本次事務(wù)到底應(yīng)該 Commit 還是 Rollback。

在前面介紹過(guò)的幾種一致性算法中，都是通過(guò)一個(gè) Leader 進(jìn)程進(jìn)行協(xié)調(diào)，在 2PC（兩階段）和 3PC（三階段）中也是一樣的解決辦法。二階段和三階段提交協(xié)議都是引入了一個(gè)協(xié)調(diào)者的組件來(lái)統(tǒng)一調(diào)度所有分布式節(jié)點(diǎn)的執(zhí)行，讓當(dāng)前節(jié)點(diǎn)知道其他節(jié)點(diǎn)的任務(wù)執(zhí)行狀態(tài)，通過(guò)通知和表決的方式，決定執(zhí)行 Commit 還是 Rollback 操作。

二階段提交協(xié)議

二階段提交算法的成立是基于以下假設(shè)的：

• 在該分布式系統(tǒng)中，存在一個(gè)節(jié)點(diǎn)作為 協(xié)調(diào)者（Coordinator），其他節(jié)點(diǎn)作為 參與者（Participants），且節(jié)點(diǎn)之間可以進(jìn)行網(wǎng)絡(luò)通信；

• 所有節(jié)點(diǎn)都采用預(yù)寫式日志，日志被寫入后被保存在可靠的存儲(chǔ)設(shè)備上，即使節(jié)點(diǎn)損壞也不會(huì)導(dǎo)致日志數(shù)據(jù)的丟失；

• 所有節(jié)點(diǎn)不會(huì)永久性損壞，即使損壞后仍然可以恢復(fù)。

兩階段提交中的兩個(gè)階段，指的是 Commit-request 階段 和 Commit 階段，兩階段提交的流程如下：

提交請(qǐng)求階段

在提交請(qǐng)求階段，協(xié)調(diào)者將通知事務(wù)參與者準(zhǔn)備提交事務(wù)，然后進(jìn)入表決過(guò)程。在表決過(guò)程中，參與者將告知協(xié)調(diào)者自己的決策：同意（事務(wù)參與者本地事務(wù)執(zhí)行成功）或取消（本地事務(wù)執(zhí)行故障），在第一階段，參與節(jié)點(diǎn)并沒(méi)有進(jìn)行Commit操作。

提交階段

在提交階段，協(xié)調(diào)者將基于第一個(gè)階段的投票結(jié)果進(jìn)行決策：提交或取消這個(gè)事務(wù)。這個(gè)結(jié)果的處理和前面基于半數(shù)以上投票的一致性算法不同，必須當(dāng)且僅當(dāng)所有的參與者同意提交，協(xié)調(diào)者才會(huì)通知各個(gè)參與者提交事務(wù)，否則協(xié)調(diào)者將通知各個(gè)參與者取消事務(wù)。

參與者在接收到協(xié)調(diào)者發(fā)來(lái)的消息后將執(zhí)行對(duì)應(yīng)的操作，也就是本地 Commit 或者 Rollback。

兩階段提交存在的問(wèn)題

兩階段提交協(xié)議有幾個(gè)明顯的問(wèn)題，下面列舉如下。

• 資源被同步阻塞

在執(zhí)行過(guò)程中，所有參與節(jié)點(diǎn)都是事務(wù)獨(dú)占狀態(tài)，當(dāng)參與者占有公共資源時(shí)，那么第三方節(jié)點(diǎn)訪問(wèn)公共資源會(huì)被阻塞。

• 協(xié)調(diào)者可能出現(xiàn)單點(diǎn)故障

一旦協(xié)調(diào)者發(fā)生故障，參與者會(huì)一直阻塞下去。

• 在 Commit 階段出現(xiàn)數(shù)據(jù)不一致

在第二階段中，假設(shè)協(xié)調(diào)者發(fā)出了事務(wù) Commit 的通知，但是由于網(wǎng)絡(luò)問(wèn)題該通知僅被一部分參與者所收到并執(zhí)行 Commit，其余的參與者沒(méi)有收到通知，一直處于阻塞狀態(tài)，那么，這段時(shí)間就產(chǎn)生了數(shù)據(jù)的不一致性。

三階段提交協(xié)議

為了解決二階段協(xié)議中的同步阻塞等問(wèn)題，三階段提交協(xié)議在協(xié)調(diào)者和參與者中都引入了超時(shí)機(jī)制，并且把兩階段提交協(xié)議的第一個(gè)階段拆分成了兩步：詢問(wèn)，然后再鎖資源，最后真正提交。

三階段中的 Three Phase 分別為 CanCommit、PreCommit、DoCommit 階段。

CanCommit 階段

3PC 的 CanCommit 階段其實(shí)和 2PC 的準(zhǔn)備階段很像。協(xié)調(diào)者向參與者發(fā)送 Can-Commit 請(qǐng)求，參與者如果可以提交就返回 Yes 響應(yīng)，否則返回 No 響應(yīng)。

PreCommit 階段

協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來(lái)決定是否可以繼續(xù)事務(wù)的 PreCommit 操作。根據(jù)響應(yīng)情況，有以下兩種可能。

A. 假如協(xié)調(diào)者從所有的參與者獲得的反饋都是 Yes 響應(yīng)，那么就會(huì)進(jìn)行事務(wù)的預(yù)執(zhí)行：

• 發(fā)送預(yù)提交請(qǐng)求，協(xié)調(diào)者向參與者發(fā)送 PreCommit 請(qǐng)求，并進(jìn)入 Prepared 階段；

• 事務(wù)預(yù)提交，參與者接收到 PreCommit 請(qǐng)求后，會(huì)執(zhí)行事務(wù)操作；

• 響應(yīng)反饋，如果參與者成功執(zhí)行了事務(wù)操作，則返回 ACK 響應(yīng)，同時(shí)開(kāi)始等待最終指令。

B. 假如有任何一個(gè)參與者向協(xié)調(diào)者發(fā)送了 No 響應(yīng)，或者等待超時(shí)之后，協(xié)調(diào)者都沒(méi)有接到參與者的響應(yīng)，那么就中斷事務(wù)：

• 發(fā)送中斷請(qǐng)求，協(xié)調(diào)者向所有參與者發(fā)送 abort 請(qǐng)求；

• 中斷事務(wù)，參與者收到來(lái)自協(xié)調(diào)者的 abort 請(qǐng)求之后，執(zhí)行事務(wù)的中斷。

DoCommit 階段

該階段進(jìn)行真正的事務(wù)提交，也可以分為以下兩種情況。

A. 執(zhí)行提交

• 發(fā)送提交請(qǐng)求。協(xié)調(diào)者接收到參與者發(fā)送的 ACK 響應(yīng)后，那么它將從預(yù)提交狀態(tài)進(jìn)入到提交狀態(tài)，并向所有參與者發(fā)送 doCommit 請(qǐng)求。

• 事務(wù)提交。參與者接收到 doCommit 請(qǐng)求之后，執(zhí)行正式的事務(wù)提交，并在完成事務(wù)提交之后釋放所有事務(wù)資源。

• 響應(yīng)反饋。事務(wù)提交完之后，向協(xié)調(diào)者發(fā)送 ACK 響應(yīng)。

• 完成事務(wù)。協(xié)調(diào)者接收到所有參與者的 ACK 響應(yīng)之后，完成事務(wù)。

B. 中斷事務(wù)

協(xié)調(diào)者沒(méi)有接收到參與者發(fā)送的 ACK 響應(yīng)，可能是因?yàn)榻邮苷甙l(fā)送的不是 ACK 響應(yīng)，也有可能響應(yīng)超時(shí)了，那么就會(huì)執(zhí)行中斷事務(wù)。

C.超時(shí)提交

參與者如果沒(méi)有收到協(xié)調(diào)者的通知，超時(shí)之后會(huì)執(zhí)行 Commit 操作。

三階段提交做了哪些改進(jìn)

引入超時(shí)機(jī)制

在 2PC 中， 只有協(xié)調(diào)者擁有超時(shí)機(jī)制，如果在一定時(shí)間內(nèi)沒(méi)有收到參與者的消息則默認(rèn)失敗，3PC 同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制。

添加預(yù)提交階段

在 2PC 的準(zhǔn)備階段和提交階段之間，插入一個(gè)準(zhǔn)備階段，使 3PC 擁有 CanCommit、PreCommit、DoCommit 三個(gè)階段，PreCommit 是一個(gè)緩沖，保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。

三階段提交協(xié)議存在的問(wèn)題

三階段提交協(xié)議同樣存在問(wèn)題，具體表現(xiàn)為，在階段三中，如果參與者接收到了 PreCommit 消息后，出現(xiàn)了不能與協(xié)調(diào)者正常通信的問(wèn)題，在這種情況下，參與者依然會(huì)進(jìn)行事務(wù)的提交，這就出現(xiàn)了數(shù)據(jù)的不一致性。

兩階段和三階段提交的應(yīng)用

兩階段提交是一種比較精簡(jiǎn)的一致性算法/協(xié)議，很多關(guān)系型數(shù)據(jù)庫(kù)都是采用兩階段提交協(xié)議來(lái)完成分布式事務(wù)處理的，典型的比如 MySQL 的 XA 規(guī)范。

在事務(wù)處理、數(shù)據(jù)庫(kù)和計(jì)算機(jī)網(wǎng)絡(luò)中，兩階段提交協(xié)議提供了分布式設(shè)計(jì)中的數(shù)據(jù)一致性的保障，整個(gè)事務(wù)的參與者要么一致性全部提交成功，要么全部回滾。MySQL Cluster 內(nèi)部數(shù)據(jù)的同步就是用的 2PC 協(xié)議。

MySQL 的主從復(fù)制

在 MySQL 中，二進(jìn)制日志是 server 層，主要用來(lái)做 主從復(fù)制 和 即時(shí)點(diǎn)恢復(fù) 時(shí)使用的；而事務(wù)日志（Redo Log）是 InnoDB 存儲(chǔ)引擎層，用來(lái)保證事務(wù)安全的。

在數(shù)據(jù)庫(kù)運(yùn)行中，需要保證 Binlog 和 Redo Log 的一致性，如果順序不一致， 則意味著 Master-Slave 可能不一致。

在開(kāi)啟 Binlog 后，如何保證 Binlog 和 InnoDB redo 日志的一致性呢？MySQL 使用的就是二階段提交，內(nèi)部會(huì)自動(dòng)將普通事務(wù)當(dāng)做一個(gè) XA 事務(wù)（內(nèi)部分布式事務(wù)）來(lái)處理：

• Commit 會(huì)被自動(dòng)的分成 Prepare 和 Commit 兩個(gè)階段；

• Binlog 會(huì)被當(dāng)做事務(wù)協(xié)調(diào)者（Transaction Coordinator），Binlog Event 會(huì)被當(dāng)做協(xié)調(diào)者日志。

關(guān)于 XA 規(guī)范的具體實(shí)現(xiàn)，會(huì)在后面的課時(shí)中分享。

總結(jié)

兩階段和三階段提交協(xié)議是眾多分布式算法的基礎(chǔ)，這一課時(shí)介紹了兩階段提交和三階段提交的具體流程，兩種協(xié)議的區(qū)別，以及兩階段提交在 MySQL 主從復(fù)制中的應(yīng)用。