隨著微服務架構在各個企業的滲透，大家都在紛紛的將技術架構轉型，從單體式應用變成微服務架構式，從單機部署變分布式部署，我們的應用也變成了分布式應用。在分布式應用中，一切就變得復雜了，如何保障數據的一致性變為最重要的問題。在金九銀十的跳槽季中，分布式事務也成為面試中的必考題，因此今天給大家惡補一波分布式事務知識，祝大家可以找到一個滿意的工作。

在單體式應用中，因為所有的事務（即某個動作的全流程，比如購物包含付款、下訂單、減庫存三個操作）都在一個環境里完成，自然可以保障操作的原子性（事務要么全部成功，要么全部失敗）、一致性（事務執行前后，數據從一個狀態到另一個狀態必須是一致的）、隔離性（多個并發事務相互隔離，互不干擾）、持久性（事務完成后，對于數據庫的更改是永久保存的，不能回滾）。而在微服務架構的分布式應用中，事務變成了分布式事務（即事務的參與者、支持事務的服務器、資源服務器、事務服務器分別位于不同的分布式系統的不同節點上），一個操作拆分成了多個服務完成，一個服務又在多臺機器上完成。

那么在分布式事務中，如何保障事務的一致性呢？解決辦法是基于XA協議進行擴展的2PC兩階段提交、3PC三階段提交、TCC試驗確認取消方案。那么XA協議是什么呢？它是一個基于數據庫的分布式事務協議，包含事務管理器、本地資源管理器，事務管理器作為全局的調度者，對本地資源管理器同一提交或回滾。

我們先來看看2PC（2phasecommit）兩階段提交，它包含兩個階段的提交，第一階段是準備階段，事務管理器（即協調者）詢問資源管理器（即參與者）“老鐵，準備好了沒有啊？可以進行相關操作了嗎？”，資源管理器根據自己的情況回答，如果準備好了就會反饋”老板，我這里都準備好了，可以安排對應的工作了“。第二階段是執行階段，事務管理器給資源管理器提交一個用戶請求，比如創建訂單，資源管理器就會進行訂單的創建，在創建完成之后，把執行結果返回給事務管理器。如果事務管理器收到某一個資源管理器的失敗消息，則直接給所有的資源管理器發送回滾小心，釋放事務處理過程中被占用的資源。

在這里，你可能覺得2PC已經很完美了，因為每個事務操作它都先詢問再操作，有異常就回滾，在分布式系統中完完全全的保障了數據的一致性。其實不然，它也存在著很多問題，比如如果在第二階段，事務管理器向資源管理器發送提交命令后，出現網絡異常請求，只有部分資源管理器收到消息并執行了命令，其它沒有收到提交命令的資源協調器就沒有辦法執行事務，從而導致了整個分布式系統的數據不一致。比如如果事務管理器出現了問題，資源管理器都還處在等待命令的情況，就沒有辦法完成事務的操作。

道高一尺，魔高一丈，我們有了3PC（3PhaseCommit）三階段提交，可以把它認為是2PC的升級版。所謂3PC它包含三個階段cancommit、precommit、docommit。相比兩階段提交，它多了一個precommit準備階段，確保在最后提交階段之前，各個參與者資源管理器的狀態都一致。并且還增加了超時機制，如果協調者事務管理器出現了問題，參與者資源管理器不會一直等待，而是會執行命令。

在3PC中，第一階段cancommit，協調者會給所有的參與者發送命令，詢問他們是否可以干活？各個參與者根據自己的情況進行應答，在第一階段確認了所有參與者都可以干活后。第二階段precommit，協調者給所有的參與者發送precommit命令，詢問是否可以先做些準備工作，參與者收到命令后，會根據自己的情況判斷是否執行操作，如果可以則會返回Yes，在協調者收到所有參與者的Yes命令后。第三階段docommit，所有的參與者執行事務操作，該加庫存的加庫存、下訂單的下訂單，完成任務后返回協調者“任務執行完畢”。

TCC（try-confirm-cancel）是補償業務，可以把它理解為在業務層面對事務一致性的保障。2PC、3PC更多是在數據庫層面去保障各個節點的數據一致性。在TCC中，針對每一個操作都需要確認和補償，當用戶請求過來時，通過分布式事務協調器進行事務的啟動，在try階段時是通過try操作去扣除服務的預留資源；然后通過分布式事務協調器去提交事務，在confirm階段是確認執行業務操作后，在預留的資源基礎上進行購買請求；在cancel階段是處理某個服務的資源尚未預留成功時，取消所有資源的預留請求。

TCC方案倒是很好的保障了數據一致性，但是它也存在一些問題，比如對業務有入侵，我們看到每個服務的操作都包含try、confirm、cancel。