當下互聯網發展如火如荼，絕大部分公司都進行了數據庫拆分和服務化(SOA)。在這種情況下，完成某一個業務功能可能需要橫跨多個服務，操作多個數據庫。這就涉及到了分佈式事務，用需要操作的資源位於多個資源服務器上，而應用需要保證對於多個資源服務器的數據的操作，要麼全部成功，要麼全部失敗。本質上來說，分佈式事務就是爲了保證不同資源服務器的數據一致性。
最早的分佈式事務應用架構很簡單，不涉及服務間的訪問調用，僅僅是服務內操作涉及到對多個數據庫資源的訪問，如下圖所示。
當一個服務操作訪問不同的數據庫資源，又希望對它們的訪問具有事務特性時，就需要採用分佈式事務來協調所有的事務參與者。
典型的應用場景如分表分庫中的事務。通常一個庫數據量比較大或者預期未來的數據量比較大，都會進行水平拆分，也就是分庫分表。對於分庫分表的情況，一般開發人員都會使用一些數據庫中間件來降低SQL操作的複雜性。如:INSERT INTO user(id, name) VALUES (1,“張三”),(2,“李四”);這條SQL是操作單庫的語法，單庫情況下，可以保證事務的一致性。但是由於現在進行了分庫分表，開發人員希望將1號記錄插入分庫1，2號記錄插入分庫2。所以數據庫中間件要將其改寫爲2條SQL，分別插入兩個不同的分庫，此時要保證兩個庫要不都成功，要不都失敗，因此基本上所有的數據庫中間件都面臨着分佈式事務的問題。
對於上面介紹的分佈式事務應用架構，儘管一個服務操作會訪問多個數據庫資源，但是畢竟整個事務還是控制在單一服務的內部。如果一個服務操作需要調用另外一個服務，這時的事務就需要跨越多個服務了。在這種情況下，起始於某個服務的事務在調用另外一個服務的時候，需要以某種機制流轉到另外一個服務，從而使被調用的服務訪問的資源也自動加入到該事務當中來。下圖反映了這樣一個跨越多個服務的分佈式事務。
舉個簡單的例子，一個公司之內，用戶的資產可能分爲好多個部分，比如餘額，積分，優惠券等等，如下圖所示。
在公司內部有可能積分功能由一個微服務團隊維護，優惠券又是另外的團隊維護，這樣的話就無法保證積分扣減了之後，優惠券能否扣減成功。所以這裏也需要使用分佈式事務來控制。
如果將上面這兩種場景（一個服務可以調用多個數據庫資源，也可以調用其他服務）結合在一起，對此進行延伸，整個分佈式事務的參與者將會組成如下圖所示的樹形拓撲結構。在一個跨服務的分佈式事務中，事務的發起者和提交均系同一個，它可以是整個調用的客戶端，也可以是客戶端最先調用的那個服務。
上述討論的分佈式事務場景中，無一例外的都直接或者間接的操作了多個數據庫。如何保證事務的ACID特性，對於分佈式事務實現方案而言，是非常大的挑戰。同時，分佈式事務實現方案還必須要考慮性能的問題，如果爲了嚴格保證ACID特性，導致性能嚴重下降，那麼對於一些要求快速響應的業務，是無法接受的。