一、典型的分布式事務(wù)實例

跨行轉(zhuǎn)賬問題是一個典型的分布式事務(wù)，用戶A向B的一個轉(zhuǎn)賬1000，要進行A的余額-1000，B的余額+1000，顯然必須保證這兩個操作的事務(wù)性。

類似的還有，電商系統(tǒng)中，當有用戶下單后，除了在訂單表插入記，還要在商品表更新庫存等，特別是隨著微服務(wù)架構(gòu)的流行，分布式事務(wù)的場景更變得更普遍。

二、什么是二階段提交協(xié)議？

二階段提交協(xié)議(2PC)通常用來保證數(shù)據(jù)的強一致性，二階段提交協(xié)議(2PC)中存在兩種類型的節(jié)點：協(xié)調(diào)節(jié)點和數(shù)據(jù)節(jié)點(或稱協(xié)調(diào)者與參與者)，數(shù)據(jù)節(jié)點可以說是數(shù)據(jù)在多個節(jié)點的備份，協(xié)調(diào)節(jié)點用戶協(xié)調(diào)管理多個數(shù)據(jù)節(jié)點在事務(wù)操作中數(shù)據(jù)的一致性問題；

2PC(Two Phase Commit)協(xié)議通常分為兩個階段進行，提交請求階段(Commit Request Phase)或稱投票階段(Voting phase)、與提交階段(Commit Phase)；

1.提交請求階段(Commit Request Phase)，協(xié)調(diào)者發(fā)送請求給參與者，通知參與者提交或取消事務(wù)，參與者進入投票過程，每個參與者回復(fù)給協(xié)調(diào)者自己的投票：同意(事務(wù)在本地執(zhí)行成功)或取消(事務(wù)本地執(zhí)行失敗)。

2.提交階段(Commit Phase)，協(xié)調(diào)者對上一階段參與者的投票結(jié)果進行表決，當所有投票為“同意”時提交提交事務(wù)，否者中止事務(wù)，并通知參與者，參與者接到通知后執(zhí)行相應(yīng)的操作。

2PC(TWO Phase Commit)假定節(jié)點沒有崩潰、任意兩個節(jié)點的網(wǎng)絡(luò)都是正常連通的、在寫日志的過程中數(shù)據(jù)不會丟失的前提下。

三、兩階段提交協(xié)議交互構(gòu)成描述

兩階段提交協(xié)議是協(xié)調(diào)所有分布式原子事務(wù)參與者，并決定提交或取消(回滾)的分布式算法。

1.協(xié)議參與者

在兩階段提交協(xié)議中，系統(tǒng)一般包含兩類機器(或節(jié)點)：一類為協(xié)調(diào)者(coordinator)，通常一個系統(tǒng)中只有一個；另一類為事務(wù)參與者(participants，cohorts或workers)，一般包含多個，在數(shù)據(jù)存儲系統(tǒng)中可以理解為數(shù)據(jù)副本的個數(shù)。協(xié)議中假設(shè)每個節(jié)點都會記錄寫前日志(write-ahead log)并持久性存儲，即使節(jié)點發(fā)生故障日志也不會丟失。協(xié)議中同時假設(shè)節(jié)點不會發(fā)生永久性故障而且任意兩個節(jié)點都可以互相通信。

2.兩個階段的執(zhí)行

1.請求階段(commit-request phase，或稱表決階段，voting phase)

在請求階段，協(xié)調(diào)者將通知事務(wù)參與者準備提交或取消事務(wù)，然后進入表決過程。

在表決過程中，參與者將告知協(xié)調(diào)者自己的決策：同意(事務(wù)參與者本地作業(yè)執(zhí)行成功)或取消(本地作業(yè)執(zhí)行故障)。

2.提交階段(commit phase)

在該階段，協(xié)調(diào)者將基于第一個階段的投票結(jié)果進行決策：提交或取消。

當且僅當所有的參與者同意提交事務(wù)協(xié)調(diào)者才通知所有的參與者提交事務(wù)，否則協(xié)調(diào)者將通知所有的參與者取消事務(wù)。

參與者在接收到協(xié)調(diào)者發(fā)來的消息后將執(zhí)行響應(yīng)的操作。

(3)兩階段提交的缺點

1.同步阻塞問題。執(zhí)行過程中，所有參與節(jié)點都是事務(wù)阻塞型的。

當參與者占有公共資源時，其他第三方節(jié)點訪問公共資源不得不處于阻塞狀態(tài)。

2.單點故障。由于協(xié)調(diào)者的重要性，一旦協(xié)調(diào)者發(fā)生故障。

參與者會一直阻塞下去。尤其在第二階段，協(xié)調(diào)者發(fā)生故障，那么所有的參與者還都處于鎖定事務(wù)資源的狀態(tài)中，而無法繼續(xù)完成事務(wù)操作。(如果是協(xié)調(diào)者掛掉，可以重新選舉一個協(xié)調(diào)者，但是無法解決因為協(xié)調(diào)者宕機導(dǎo)致的參與者處于阻塞狀態(tài)的問題)

3.數(shù)據(jù)不一致。在二階段提交的階段二中，當協(xié)調(diào)者向參與者發(fā)送commit請求之后，發(fā)生了局部網(wǎng)絡(luò)異常或者在發(fā)送commit請求過程中協(xié)調(diào)者發(fā)生了故障，這回導(dǎo)致只有一部分參與者接受到了commit請求。

而在這部分參與者接到commit請求之后就會執(zhí)行commit操作。但是其他部分未接到commit請求的機器則無法執(zhí)行事務(wù)提交。于是整個分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)部一致性的現(xiàn)象。

(4)兩階段提交無法解決的問題

當協(xié)調(diào)者出錯，同時參與者也出錯時，兩階段無法保證事務(wù)執(zhí)行的完整性。

考慮協(xié)調(diào)者再發(fā)出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了。

那么即使協(xié)調(diào)者通過選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者，這條事務(wù)的狀態(tài)也是不確定的，沒人知道事務(wù)是否被已經(jīng)提交。

總結(jié)

以上是生活随笔為你收集整理的java 二阶段提交,二阶段提交协议（Two Phase Commitment Protocol）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。