001什么是分布式的XA協(xié)議？

XA協(xié)議是一個(gè)基于數(shù)據(jù)庫(kù)的分布式事務(wù)協(xié)議，其分為兩部分：事務(wù)管理器和本地資源管理器。事務(wù)管理器作為一個(gè)全局的調(diào)度者，負(fù)責(zé)對(duì)各個(gè)本地資源管理器統(tǒng)一號(hào)令提交或者回滾。二階提交協(xié)議（2PC）和三階提交協(xié)議（3PC）就是根據(jù)此協(xié)議衍生出來(lái)而來(lái)。主流的諸如Oracle、MySQL等數(shù)據(jù)庫(kù)均已實(shí)現(xiàn)了XA接口。 XA接口是雙向的系統(tǒng)接口，在事務(wù)管理器（Transaction Manager）以及一個(gè)或多個(gè)資源管理器（Resource Manager）之間形成通信橋梁。也就是說(shuō)，在基于XA的一個(gè)事務(wù)中，我們可以針對(duì)多個(gè)資源進(jìn)行事務(wù)管理，例如一個(gè)系統(tǒng)訪問(wèn)多個(gè)數(shù)據(jù)庫(kù)，或即訪問(wèn)數(shù)據(jù)庫(kù)、又訪問(wèn)像消息中間件這樣的資源。這樣我們就能夠?qū)崿F(xiàn)在多個(gè)數(shù)據(jù)庫(kù)和消息中間件直接實(shí)現(xiàn)全部提交、或全部取消的事務(wù)。XA規(guī)范不是java的規(guī)范，而是一種通用的規(guī)范。

002什么是2PC？

兩段提交顧名思義就是要進(jìn)行兩個(gè)階段的提交：
第一階段，準(zhǔn)備階段(投票階段)；
第二階段，提交階段(執(zhí)行階段);

003兩段提交（2PC）的缺點(diǎn)？

二階段提交看似能夠提供原子性的操作，但它存在著嚴(yán)重的缺陷： 
1)網(wǎng)絡(luò)抖動(dòng)導(dǎo)致的數(shù)據(jù)不一致:第二階段中協(xié)調(diào)者向參與者發(fā)送commit命令之后，一旦此時(shí)發(fā)生網(wǎng)絡(luò)抖動(dòng)，導(dǎo)致一部分參與者接收到了commit請(qǐng)求并執(zhí)行，可其他未接到commit請(qǐng)求的參與者無(wú)法執(zhí)行事務(wù)提交。進(jìn)而導(dǎo)致整個(gè)分布式系統(tǒng)出現(xiàn)了數(shù)據(jù)不一致。 
2)超時(shí)導(dǎo)致的同步阻塞問(wèn)題：2PC中的所有的參與者節(jié)點(diǎn)都為事務(wù)阻塞型，當(dāng)某一個(gè)參與者節(jié)點(diǎn)出現(xiàn)通信超時(shí)，其余參與者都會(huì)被動(dòng)阻塞占用資源不能釋放。 3)單點(diǎn)故障的風(fēng)險(xiǎn):由于嚴(yán)重的依賴協(xié)調(diào)者，一旦協(xié)調(diào)者發(fā)生故障，而此時(shí)參與者還都處于鎖定資源的狀態(tài)，無(wú)法完成事務(wù)commit操作。雖然協(xié)調(diào)者出現(xiàn)故障后，會(huì)重新選舉一個(gè)協(xié)調(diào)者，可無(wú)法解決因前一個(gè)協(xié)調(diào)者宕機(jī)導(dǎo)致的參與者處于阻塞狀態(tài)的問(wèn)題。 

004什么是3PC?

三段提交（3PC）是對(duì)兩段提交（2PC）的一種升級(jí)優(yōu)化，3PC在2PC的第一階段和第二階段中插入一個(gè)準(zhǔn)備階段。保證了在最后提交階段之前，各參與者節(jié)點(diǎn)的狀態(tài)都一致。同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制，當(dāng)參與者各種原因未收到協(xié)調(diào)者的commit請(qǐng)求后，會(huì)對(duì)本地事務(wù)進(jìn)行commit，不會(huì)一直阻塞等待，解決了2PC的單點(diǎn)故障問(wèn)題，但3PC還是沒(méi)能從根本上解決數(shù)據(jù)一致性的問(wèn)題。

3PC的三個(gè)階段分別是CanCommit、PreCommit、DoCommit： CanCommit：協(xié)調(diào)者向所有參與者發(fā)送CanCommit命令，詢問(wèn)是否可以執(zhí)行事務(wù)提交操作。如果全部響應(yīng)YES則進(jìn)入下一個(gè)階段。 PreCommit：協(xié)調(diào)者向所有參與者發(fā)送PreCommit命令，詢問(wèn)是否可以進(jìn)行事務(wù)的預(yù)提交操作，參與者接收到PreCommit請(qǐng)求后，如參與者成功的執(zhí)行了事務(wù)操作，則返回Yes響應(yīng)，進(jìn)入最終commit階段。一旦參與者中有向協(xié)調(diào)者發(fā)送了No響應(yīng)，或因網(wǎng)絡(luò)造成超時(shí)，協(xié)調(diào)者沒(méi)有接到參與者的響應(yīng)，協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求，參與者接受abort命令執(zhí)行事務(wù)的中斷。 DoCommit：在前兩個(gè)階段中所有參與者的響應(yīng)反饋均是YES后，協(xié)調(diào)者向參與者發(fā)送DoCommit命令正式提交事務(wù)，如協(xié)調(diào)者沒(méi)有接收到參與者發(fā)送的ACK響應(yīng)，會(huì)向所有參與者發(fā)送abort請(qǐng)求命令，執(zhí)行事務(wù)的中斷。

005什么是TCC？

TCC（Try-Confirm-Cancel）又被稱補(bǔ)償事務(wù)，TCC與2PC的思想很相似，事務(wù)處理流程也很相似，但2PC是應(yīng)用于在DB層面，TCC則可以理解為在應(yīng)用層面的2PC，是需要我們編寫業(yè)務(wù)邏輯來(lái)實(shí)現(xiàn)。 TCC它的核心思想是："針對(duì)每個(gè)操作都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)（Try）和補(bǔ)償（Cancel）"。 還拿下單扣庫(kù)存解釋下它的三個(gè)操作： 
Try階段：下單時(shí)通過(guò)Try操作去扣除庫(kù)存預(yù)留資源。 
Confirm階段：確認(rèn)執(zhí)行業(yè)務(wù)操作，在只預(yù)留的資源基礎(chǔ)上，發(fā)起購(gòu)買請(qǐng)求。 
Cancel階段：只要涉及到的相關(guān)業(yè)務(wù)中，有一個(gè)業(yè)務(wù)方預(yù)留資源未成功，則取消所有業(yè)務(wù)資源的預(yù)留請(qǐng)求。

006TCC 事務(wù)機(jī)制相比于 2PC，解決了其幾個(gè)缺點(diǎn)?

1)解決了協(xié)調(diào)者單點(diǎn)，由主業(yè)務(wù)方發(fā)起并完成這個(gè)業(yè)務(wù)活動(dòng)。業(yè)務(wù)活動(dòng)管理器也變成多點(diǎn)，引入集群。
2)同步阻塞：引入超時(shí)，超時(shí)后進(jìn)行補(bǔ)償，并且不會(huì)鎖定整個(gè)資源，將資源轉(zhuǎn)換為業(yè)務(wù)邏輯形式，粒度變小。
3)數(shù)據(jù)一致性，有了補(bǔ)償機(jī)制之后，由業(yè)務(wù)活動(dòng)管理器控制一致性。
總之，TCC 就是通過(guò)代碼人為實(shí)現(xiàn)了兩階段提交，不同的業(yè)務(wù)場(chǎng)景所寫的代碼都不一樣，并且很大程度的增加了業(yè)務(wù)代碼的復(fù)雜度。因此，這種模式并不能很好地被復(fù)用。

007TCC的缺點(diǎn)?

應(yīng)用侵入性強(qiáng)：TCC由于基于在業(yè)務(wù)層面，至使每個(gè)操作都需要有try、confirm、cancel三個(gè)接口。
開發(fā)難度大：代碼開發(fā)量很大，要保證數(shù)據(jù)一致性confirm和cancel接口還必須實(shí)現(xiàn)冪等性。