在當今的分布式系統中，數據的一致性和事務的處理成為了關鍵問題。隨著應用程式的規模不斷擴大和復雜性的增加，單一資料庫事務的能力已經無法滿足需求。因此，引入了分布式事務的概念，以確保跨多個節點的操作能夠保持一致性。
題目
什麽情況下需要使用分布式事務，有哪些方案？
更多面試題目請見
推薦解析
是什麽？
一般在跨多個資料庫、或者不同服務的情況下需要用到分布式事務，比如訂單服務和庫存服務，下訂單和扣庫存屬於不同服務的方法，因此本地事務無法保證一致性，需要引入分布式服務。
分布式事務是由多個本地事務組成的 ，分布式事務跨越了多裝置，之間又經歷的復雜的網路，可想而知想要實作嚴格的事務道路阻且長。
我們就先來看看常見的分布式事務方案：2PC、3PC、TCC、本地訊息、事務訊息。
2PC
2PC，Two-phase commit protocol，即兩階段送出協定。它引入了一個事務協調者角色，來管理各個參與者（就是各資料庫資源）。
整體分為兩個階段，分別是準備階段和送出/回滾階段。
我們先來看看第一個階段，即準備階段。
由事務協調者給每個參與者發送準備命令，每個參與者收到命令之後會執行相關事務操作，你可以認為除了事務的送出啥都做了。
然後每個參與者會返回響應告知協調者自己是否準備成功。
協調者收到每個參與者的響應之後就進入第二階段 ，根據收集的響應，如果有一個參與者響應準備失敗那麽就向所有參與者發送回滾命令，反之發送送出命令。
這個協定其實很符合正常的思維，就像我們大學上課點名的時候，其實老師就是協調者的角色，我們都是參與者。
老師一個一個的點名，我們一個一個的喊到，最後老師收到所有同學的到之後就開始了今天的講課。
而和點名有所不同的是， 老師發現某幾個學生不在還是能繼續上課，而我們的事務可不允許這樣 。
事務協調者在第一階段未收到個別參與者的響應，則等待一定時間就會認為事務失敗，會發送回滾命令，所以在 2PC 中事務協調者有超時機制。
我們再來分析一下 2PC 的優缺點。
2PC 的優點 是能利用資料庫自身的功能進行本地事務的送出和回滾，也就是說送出和回滾實際操作不需要我們實作，不侵入業務邏輯由資料庫完成，在之後講解 TCC 之後相信大家對這點會有所體會。
2PC 主要有三大缺點 ：同步阻塞、單點故障和數據不一致問題。
同步阻塞
可以看到在第一階段執行了準備命令後，我們 每個本地資源都處於釘選狀態 ，因為除了事務的送出之外啥都做了。
所以這時候如果原生的其他請求要存取同一個資源，比如要修改商品表 id 等於 100 的那條數據，那麽此時是被阻塞住的，必須等待前面事務的完結，收到送出/回滾命令執行完釋放資源後，這個請求才能得以繼續。
所以假設這個分布式事務涉及到很多參與者，然後有些參與者處理又特別復雜，特別慢，那麽那些處理快的節點也得等著，所以說效率有點低。
單點故障
可以看到這個 單點就是協調者，如果協調者掛了整個事務就執行不下去了 。
如果協調者在發送準備命令前掛了還行，畢竟每個資源都還未執行命令，那麽資源是沒被釘選的。
可怕的是在發送完準備命令之後掛了，這時候每個本地資源都執行完處於釘選狀態了，都杵著了，這就很僵硬了，如果是某個熱點資源都阻塞了，這估計就要完蛋了。
數據不一致問題
因為協調者和參與者之間的交流是經過網路的，而網路有時候就會抽風的或者發生局部網路異常。
那麽就有可能導致某些參與者無法收到協調者的請求，而某些收到了。比如是送出請求，然後那些收到命令的參與者就送出事務了，此時就產生了數據不一致的問題。
小結一下 2PC
至此我們來先小結一些 2PC ，它是一個同步阻塞的強一致性兩階段送出協定，分別是準備階段和送出/回滾階段。
2PC 的優勢在於對業務沒有侵入，可以利用資料庫自身機制來進行事務的送出和回滾。
它的缺點：是一個同步阻塞協定，會導致高延遲和效能的下降，並且存在協調者單點故障問題，極端情況下會有數據不一致的問題。
當然這只是協定，具體的落地還是可以變通了 ，比如協調者單點問題，我就搞個主從來實作協調者，對吧。
分布式資料庫的 2PC 改進模型
可能有些人對分布式資料庫不熟悉，沒有關系，我們主要學的是思想，看看人家的思路。
我簡單的講下 Percolator 模型， 它是基於分布式儲存系統 BigTable 建立的模型 ，BigTable 是啥也不清楚的同學沒有關系影響不大。
還是拿轉賬的例子來說，我現在有 200 塊錢，你現在有 100 塊錢，為了突出重點我也不按正常的結構來畫這個表。
然後我要轉 100 塊給你。
此時事務管理器發起了準備請求，然後我賬上的錢就少了，你賬上的錢就多了，而且 事務管理器還記錄下這次操作的日誌 。
此時的數據還是私有版本，別的事務是讀不到的，簡單的理解 Lock 上有值就還是私有的。
可以看到我的記錄 Lock 標記的是 PK，你的記錄標記的是指向我的記錄指標，這個 PK 是隨機選擇的。
然後事務管理器會向被選擇作為 PK 的那條記錄發起送出指令。
此時就會把我的記錄的鎖給抹去了，這等於我的記錄不再是私有版本了，別的事務就都能存取了。
那你的記錄上還有鎖啊？不用更新嗎？
嘿嘿不需要及時更新，因為存取你的這條記錄的時候會去根據指標找我的那個記錄，發現記錄已經送出了所以你的記錄就可以被存取了。
有人說這效率不就差了，每次都要去找一次，別急。
後台會有個執行緒來掃描，然後更新把鎖記錄給去了。
這不就穩了嘛。
相比於 2PC 的改進
首先 Percolator 在送出階段不需要和所有的參與者互動，主需要和一個參與者打交道，所以這個送出是原子的！ 解決了數據不一致問題 。
然後事務管理器會記錄操作日誌，這樣當事務管理器掛了之後選舉的新事務管理器就可以透過日誌來得知當前的情況從而繼續工作， 解決了單點故障問題 。
並且 Percolator 還會有後台執行緒，會掃描事務狀況，在事務管理器宕機之後會回滾各個參與者上的事務。
可以看到相對於 2PC 還是做了很多改進的，也是巧妙的。
其實分布式資料庫還有別的事務模型，不過我也不太熟悉，就不多嗶嗶了，有興趣的同學可以自行了解。
還是挺能拓寬思想的。
其他補充
魚聰明 AI 的回答：
魚聰明 AI 地址：https://www.yucongming.com/
XA（eXtended Architecture）
XA 是一個由 X/Open 和 Open Group 提出的標準，用於在分布式事務環境中管理多個檔案總管（如資料庫或訊息佇列）的事務性操作。XA 提供了一種協定，使得這些檔案總管能夠參與到一個全域事務中，並保證事務的 ACID 特性（原子性、一致性、隔離性和永續性）。
主要特點和機制 ：
兩階段送出（2PC） ：XA 協定的核心機制是兩階段送出。在兩階段送出中，事務協調者（Transaction Coordinator）協調多個參與者（Participants）的檔案總管，確保所有參與者要麽都送出事務，要麽都回滾事務，從而保證事務的一致性。
全域事務管理 ：XA 提供了一個全域事務管理的框架，允許應用程式在多個不同的資料庫或資源上執行操作，並以全域的方式進行事務管理。
適用場景 ：
需要跨多個資料庫或資源的事務操作，例如在訂單和庫存之間保持一致性。
需要嚴格的 ACID 特性和數據一致性保證。
優點 ：
提供了強一致性和可靠性的事務處理能力。
標準化的介面和協定，方便使用和實作。
缺點 ：
效能損耗較大，特別是在分布式環境下網路延遲較高時。
存在單點故障問題，事務協調者故障會導致整個系統的事務受影響。
TCC（Try-Confirm-Cancel）
TCC 是一種基於補償事務的分布式事務解決方案，主要用於解決分布式系統中的數據一致性問題。TCC 的核心思想是將事務分解為三個階段：嘗試（Try）、確認（Confirm）和取消（Cancel），每個階段對應一個操作。
主要特點和機制 ：
三階段處理 ：TCC 事務透過 Try、Confirm 和 Cancel 三個階段來實作：
Try ：預留必須的資源，執行業務檢查。
Confirm ：確認執行，送出事務，釋放資源。
Cancel ：取消操作，釋放預留的資源，回滾事務。
補償機制 ：TCC 透過補償操作來保證最終一致性，即使在部份參與者失敗的情況下也可以進行處理。
適用場景 ：
需要高並行和低延遲的分布式系統。
需要較大的靈活性和容錯能力，例如電商交易系統中的訂單操作和庫存扣減。
業務邏輯相對復雜，不適合使用傳統的兩階段送出協定。
優點 ：
高並行和低延遲，適合大規模分布式系統。
彈性和靈活性高，能夠處理各種復雜的業務場景。
缺點 ：
實作和維護成本較高，需要額外的補償邏輯來保證最終一致性。
對業務程式碼有一定要求，需要開發者顯式地定義 Try、Confirm 和 Cancel 三個操作。
區別和選擇：
一致性級別 ：
XA 提供了強一致性，適合需要嚴格 ACID 特性的場景。
TCC 提供了最終一致性，適合需要高並行和靈活性的場景。
適用場景 ：
如果套用需要確保強一致性和數據的原子性操作，可以選擇 XA 。
如果套用可以容忍最終一致性，並且需要高並行和靈活的事務處理能力，可以選擇 TCC 。
實作復雜度 ：
XA 的實作相對較復雜，需要使用兩階段送出協定，存在效能損耗和單點故障風險。
TCC 的實作相對靈活，但需要開發者實作補償邏輯來保證最終一致性。
綜上所述，選擇合適的分布式事務處理機制應根據套用的具體要求和場景來進行權衡和選擇。
歡迎交流
本文主要介紹了分布式事務是什麽？以及兩階段送出協定和產生的問題，改進方案，下期文章繼續講述關於分布式事務的知識，文末還有三個問題，歡迎小夥伴在評論區留言！近期面試鴨小程式已全面上線，想要刷題的小夥伴可以積極參與！
1）在分布式環境中，事務可能涉及多個服務和資源。如何定義事務的邊界和管理數據隔離，以防止不同事務之間的數據幹擾和沖突？如何確保事務在跨多個服務和資源時的正確執行和管理？
2）隨著系統規模的擴大，分布式事務的管理和協調成為挑戰。如何設計分布式事務處理機制，以支持系統的水平擴充套件和高並行存取，同時保證事務的正確性和一致性？
3）分布式事務涉及多個節點和服務，因此監控和偵錯變得更加復雜。如何設計有效的監控和偵錯機制，以便及時發現和解決分布式事務中的問題，保障系統的穩定性和可靠性？
點燃求職熱情！每周持續更新，海量面試題和大廠面經等你挑戰！趕緊關註面試鴨公眾號，輕松備戰春招和暑期實習！
往期推薦
