隨著微服務架構在各個企業的滲透，大家都在紛紛的將技術架構轉型，從單體式應用變成微服務架構式，從單機部署變分佈式部署，我們的應用也變成了分佈式應用。在分佈式應用中，一切就變得複雜了，如何保障數據的一致性變為最重要的問題。在金九銀十的跳槽季中，分佈式事務也成為面試中的必考題，因此今天給大家惡補一波
分佈式事務知識，祝大家可以找到一個滿意的工作。在單體式應用中，因為所有的事務（即某個動作的全流程，比如購物包含付款、下訂單、減庫存三個操作）都在一個環境裡完成，自然可以保障操作的原子性（事務要麼全部成功，要麼全部失敗）、一致性（事務執行前後，數據從一個狀態到另一個狀態必須是一致的）、隔離性（多個併發事務相互隔離，互不干擾）、持久性（事務完成後，對於數據庫的更改是永久保存的，不能回滾）。而在微服務架構的分佈式應用中，事務變成了分佈式事務（即事務的參與者、支持事務的服務器、資源服務器、事務服務器分別位於不同的分佈式系統的不同節點上），一個操作拆分成了多個服務完成，一個服務又在多臺機器上完成。
那麼在分佈式事務中，如何保障事務的一致性呢？解決辦法是基於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。
金九銀十的跳槽季，正是尋找下一份工作的好時機。而在各大廠的面試中，分佈式事務都是常考題，通過本文的介紹，希望小編能助力大家在金九銀十的跳槽季找到一個好工作～
