一、典型的分布式事務實例

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

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

二、什么是二階段提交協議？

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

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

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

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

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

三、兩階段提交協議交互構成描述

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

1.協議參與者

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

2.兩個階段的執行

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

在請求階段，協調者將通知事務參與者準備提交或取消事務，然后進入表決過程。

在表決過程中，參與者將告知協調者自己的決策：同意(事務參與者本地作業執行成功)或取消(本地作業執行故障)。

2.提交階段(commit phase)

在該階段，協調者將基于第一個階段的投票結果進行決策：提交或取消。

當且僅當所有的參與者同意提交事務協調者才通知所有的參與者提交事務，否則協調者將通知所有的參與者取消事務。

參與者在接收到協調者發來的消息后將執行響應的操作。

(3)兩階段提交的缺點

1.同步阻塞問題。執行過程中，所有參與節點都是事務阻塞型的。

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

2.單點故障。由于協調者的重要性，一旦協調者發生故障。

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

3.數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求之后，發生了局部網絡異常或者在發送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。

而在這部分參與者接到commit請求之后就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。于是整個分布式系統便出現了數據部一致性的現象。

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

當協調者出錯，同時參與者也出錯時，兩階段無法保證事務執行的完整性。

考慮協調者再發出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了。

那么即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。