一、前言

在單個數據庫例項時候，我們可以在一個數據源的事務（本地事務）內做多步資料庫操作，在事務內的多個操作要麼全部執行生效，要麼全部不生效。在多資料例項節點時候，我們對多個例項的資料來源進行操作時候就沒辦法把多個操作放到一個大的事務內來保證原子性了，因為多個例項操作的是不同的資料來源，而資料庫自帶的事務是針對單個數據源來說的。

二、二階段協議

單個數據庫例項內的事務我們稱為本地事務，需要保證多個數據源的操作要麼都做要麼都不做的事務我們成為分散式事務，為了實現分散式事務，二階段與三階段協議就應運而生了。

分散式事務由事務發起者、資源管理器（參與者）、事務協調者組成，下面我們看看二階段協議內容：

• 第一階段
  分散式事務發起方向事務協調器發起分散式事務，協調器則向所有事務參與者發起準備請求，事務參與者接受到請求後執行本地事務，但是不提交。如果所有事務參與者都返回了準備OK到事務協調器

則事務協調器準備進入第二階段。如果有一個參與者返回準備失敗，則事務協調器向所有參與者發起事務回滾請求，事務參與者收到請求後回滾執行的本地事務，則分散式事務結束。

image.png

• 第二階段
  事務協調器向所有事務參與者發起提交事務的請求，事務參與者接受到請求後，執行本地事務的提交操作。如果事務協調器收到所有參與者提交OK則分散式事務結束。

image.png

如果協調器發現有些參與者返回事務提交失敗，則執行具體的事務補償策略。

三、總結

二階段協議是個標準協議，協議只是規定了分散式事務實現的骨架，並沒有規定具體如何實現，比如事務協調器是作為一個單獨應用存在，還是與事務發起方一起部署的？事務參與者是單獨的應用還是與發起方一起的？並且並沒有考慮異常情況，比如第二階段如果有部分參與者返回提交失敗或者由於網路原因返回了提交OK，但是事務協調器沒有收到，該怎麼處理？

另外分散式事務並不是簡單說對多個數據源操作的原子性，還可以是資料來源操作與遠端RPC的原子性，資料來源與傳送訊息的原子性。