介紹

首先用一張圖說明2PC所處的背景知識(shí)

事務(wù)的演進(jìn)

• 左邊的圖表明在同一臺(tái)機(jī)器上，幾個(gè)進(jìn)程要完成一個(gè)事務(wù)，由于在同一臺(tái)機(jī)器上共享內(nèi)存，只有進(jìn)程間的同步互斥操作，不存在消息的傳遞。
• 中間的圖表明客戶端進(jìn)程要完成一個(gè)事務(wù)（多個(gè)客戶端之間也有自己要完成的并發(fā)事務(wù)），但是事務(wù)（Lock）的管理由一臺(tái)服務(wù)器管理，這里只存在客戶端和鎖服務(wù)之間的消息傳遞，不存在鎖服務(wù)器之間的一致。
• 中間的情況必然存在Lock服務(wù)器的不安全性，因此需要backup機(jī)器，而多個(gè)機(jī)器之間需要相互同步（當(dāng)然不理解成備份機(jī)，理解成一個(gè)事務(wù)就是要跨server執(zhí)行也是可以的）。這種情況下就需要用到分布式環(huán)境下的事務(wù)提交協(xié)議或者consensus協(xié)議。

在事務(wù)進(jìn)行過程中，除了參與者在加入分布式事務(wù)時(shí)通知協(xié)調(diào)者之外，協(xié)調(diào)者和參與者之間沒有其他通信。客戶的事務(wù)提交（或放棄）請(qǐng)求直接發(fā)送給協(xié)調(diào)者。如果客戶請(qǐng)求abortTransaction，或者事務(wù)已經(jīng)被某個(gè)參與者放棄，那么協(xié)調(diào)者可以立即通知所有參與者放棄事務(wù)。只有當(dāng)客戶請(qǐng)求協(xié)調(diào)者提交事務(wù)時(shí)，兩階段提交協(xié)議才開始使用。

維基百科的解釋：

為了使基于分布式系統(tǒng)架構(gòu)下的所有節(jié)點(diǎn)在進(jìn)行事務(wù)提交時(shí)保持一致性而設(shè)計(jì)的一種算法。通常，二階段提交也被稱為是一種協(xié)議(Protocol)。在分布式系統(tǒng)中，每個(gè)節(jié)點(diǎn)雖然可以知曉自己的操作時(shí)成功或者失敗，卻無法知道其他節(jié)點(diǎn)的操作的成功或失敗。當(dāng)一個(gè)事務(wù)跨越多個(gè)節(jié)點(diǎn)時(shí)，為了保持事務(wù)的[ACID]特性，需要引入一個(gè)作為協(xié)調(diào)者的組件來統(tǒng)一掌控所有節(jié)點(diǎn)(稱作參與者)的操作結(jié)果并最終指示這些節(jié)點(diǎn)是否要把操作結(jié)果進(jìn)行真正的提交(比如將更新后的數(shù)據(jù)寫入磁盤等等)。因此，二階段提交的算法思路可以概括為： 參與者將操作成敗通知協(xié)調(diào)者，再由協(xié)調(diào)者根據(jù)所有參與者的反饋情報(bào)決定各參與者是否要提交操作還是中止操作。
因此兩階段提交協(xié)議也可以認(rèn)為是一種consensus問題的解決方式

角色：

• 客戶端：請(qǐng)求發(fā)起事務(wù)的一方
• 協(xié)調(diào)者：決定事務(wù)能夠commit或者abort的中間節(jié)點(diǎn)，顧名思義，協(xié)調(diào)其他參與者的情況
• 參與者：參與客戶端提交的決議（對(duì)為什么要有多參與者，我覺得有以下兩種場(chǎng)景可以理解：1 為了保證系統(tǒng)可靠，需要有replication，因此各個(gè)備份節(jié)點(diǎn)如何達(dá)成一致？ 2 典型的銀行事務(wù)。一個(gè)賬號(hào)給另一個(gè)賬號(hào)匯錢，但是這兩個(gè)賬號(hào)不在同一臺(tái)機(jī)器，不同的機(jī)器就是不同的參與者）

算法

算法假設(shè)

• 該分布式系統(tǒng)中，存在一個(gè)節(jié)點(diǎn)作為協(xié)調(diào)者(Coordinator)，其他節(jié)點(diǎn)作為參與者(Cohorts)。且節(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ù)。

算法描述

第一階段：

• 協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)詢問是否可以執(zhí)行提交操作，并開始等待各參與者節(jié)點(diǎn)的響應(yīng)。
• 參與者節(jié)點(diǎn)執(zhí)行詢問發(fā)起為止的所有事務(wù)操作，并將Undo信息和Redo信息寫入日志。
• 各參與者節(jié)點(diǎn)響應(yīng)協(xié)調(diào)者節(jié)點(diǎn)發(fā)起的詢問。如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行成功，則它返回一個(gè)"同意"消息；如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行失敗，則它返回一個(gè)"中止"消息。
  第二階段：
  成功，當(dāng)協(xié)調(diào)者節(jié)點(diǎn)從所有參與者節(jié)點(diǎn)獲得的相應(yīng)消息都為"同意"時(shí)：
• 協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出"正式提交"的請(qǐng)求。
• 參與者節(jié)點(diǎn)正式完成操作，并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源。
• 參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送"完成"消息。
• 協(xié)調(diào)者節(jié)點(diǎn)收到所有參與者節(jié)點(diǎn)反饋的"完成"消息后，完成事務(wù)。
  失敗，如果任一參與者節(jié)點(diǎn)在第一階段返回的響應(yīng)消息為"終止"，或者 協(xié)調(diào)者節(jié)點(diǎn)在第一階段的詢問超時(shí)之前無法獲取所有參與者節(jié)點(diǎn)的響應(yīng)消息時(shí)：
• 協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出"回滾操作"的請(qǐng)求。
• 參與者節(jié)點(diǎn)利用之前寫入的Undo信息執(zhí)行回滾，并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源。
• 參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送"回滾完成"消息。
• 協(xié)調(diào)者節(jié)點(diǎn)收到所有參與者節(jié)點(diǎn)反饋的"回滾完成"消息后，取消事務(wù)。

存在的缺陷

在分布式系統(tǒng)的設(shè)計(jì)里面，一致性和可用性往往存在矛盾，如果要求所有的機(jī)器都要完成一件事情才能認(rèn)為完成，那么這樣的系統(tǒng)必然存在可用性的問題。假設(shè)當(dāng)一臺(tái)機(jī)器發(fā)生crash或者消息不能夠及時(shí)傳遞，就會(huì)導(dǎo)致整個(gè)系統(tǒng)阻塞。2PC就是一種典型的阻塞式協(xié)議（在除第一個(gè)極端的每一個(gè)通信階段都會(huì)有阻塞的情況發(fā)生），解決阻塞的最好辦法就是引入超時(shí)機(jī)制。

• 階段1中協(xié)調(diào)者要等待所有的參與者反饋，此時(shí)如果有參與者沒有反饋（消息丟失，網(wǎng)絡(luò)分區(qū)，進(jìn)程crash），則協(xié)調(diào)者將一直等待下去。加入超時(shí)判斷時(shí)候，一定時(shí)間內(nèi)沒有收集齊則發(fā)送消息認(rèn)定操作失敗，全局廣播取消事務(wù)。
• 協(xié)調(diào)者無法服務(wù)，這個(gè)時(shí)候參與者有兩種情況。此時(shí)參與者會(huì)一直阻塞，等待協(xié)調(diào)者回復(fù)。此時(shí)解決辦法通常都是重新選舉一個(gè)協(xié)調(diào)者。
• 現(xiàn)在重新考慮協(xié)調(diào)者無法服務(wù)（協(xié)調(diào)者crash，網(wǎng)絡(luò)分區(qū)），如果是第二階段，協(xié)調(diào)者已經(jīng)發(fā)出表決之后的決定（commit or abort）之后發(fā)生錯(cuò)誤，此時(shí)參與者可以詢問其他參與者Q來決定自己的狀態(tài)：1. 如果Q已經(jīng)commit，則自己可以放心commit。 2. 如果Q已經(jīng)abort，則自己可以放心aboirt。 3. 如果Q處于INIT狀態(tài)（就是階段1剛開始的情況），此時(shí)表明協(xié)調(diào)者在階段1發(fā)送投票請(qǐng)求的時(shí)候crash或者是協(xié)調(diào)者和Q之間存在通信故障，則此時(shí)可以說明協(xié)調(diào)者不可能commit，則自己可以放心標(biāo)記為abort即可。 4. 如果Q與自己狀態(tài)相同，則需要詢問其他參與者。
• 另外我們發(fā)現(xiàn)如果出現(xiàn)網(wǎng)絡(luò)分區(qū)，可能會(huì)出現(xiàn)腦裂現(xiàn)象，此時(shí)無法確定誰才是真正的協(xié)調(diào)者。

下圖是《大數(shù)據(jù)日知錄》提供的2PC有限狀態(tài)機(jī)

IMG_0039.JPG

正因?yàn)?PC存在問題，所以之后有3PC和Paxos的方式

感覺分布式事務(wù)也可以理解成廣義的consensus問題，其實(shí)就是多個(gè)機(jī)器要完成一件All or noting的事情，多個(gè)機(jī)器的狀態(tài)必然是要同步的。