概述
分布式事務就是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點之上，以上是百度百科的解釋。
簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務器上，且屬于不同的應用，分布式事務需要保證這些小操作要么全部成功，要么全部失敗。本質上來說，分布式事務就是為了保證數據庫中的數據一致性以及原子性。
分布式事務產生的場景
查詢了下，發(fā)現網上有很多人已經總結了，這里我先搬過來，然后在分析下，因為我覺得說的不清晰。
跨JVM進程產生分布式事務
典型的場景就是微服務架構：微服務之間通過遠程調用完成各自的事務操作。比如：訂單微服務和庫存微服務，下單的同時訂單微服務請求庫存微服務減少庫存。
跨數據庫實例產生分布式事務
單體系統(tǒng)訪問多個數據庫實例當單體系統(tǒng)需要訪問多個數據庫（實例）時就會產生分布式事務。比如：用戶信息和訂單信息分別在兩個MySQL實例存儲，用戶管理系統(tǒng)刪除用戶信息，需要分別刪除用戶信息及用戶的訂單信息，由于數據分布在不同的數據實例，需要通過不同的數據庫鏈接去操作數據，此時產生分布式事務。
多服務訪問同一個數據庫實例
訂單微服務和庫存微服務即使訪問同一個數據庫也會產生分布式事務，不過這情況比較少，只有在跨服務訪問的時候才會出現。
分布式服務調用鏈路
第一種，事務嵌套
第二種，事務分離
這兩種是事務調用的最常見也是最典型的場景，但是都有一個問題，也是導致在多服務訪問同一個數據庫實例中出現分布式事務的場景：當遠程調用讓Service B成功了，由于網絡問題遠程調用并沒有返回，此時本地事務提交失敗就回滾了Service A的操作，此時Service A與Service B的數據就不一致了。
所以，不管是多數據庫還是多應用服務的場景下的應用分布式部署，對于某一個業(yè)務下(比如訂單扣減)，一旦有異常，都需要回滾，一旦事務都成功了，都需要成功；而這中間有一個最大的影響因素，就是遠程調用。由于遠程調用的阻礙性，Serivce A與Service B并不能感知到彼此的事務是否執(zhí)行成功，也就不能正確的回滾或是提交。而對于分布式解決方案的應用，其解決的就是這層遠程調用的態(tài)勢感知；即，根據各服務事務(分支事務)的執(zhí)行情況來具體判斷是否事務可以提交，而不是被遠程調用所影響。
Seata的AT模式就是中間加了一層協(xié)調器TC，管理分支事務的執(zhí)行狀態(tài)；而Sagas模式則是通過事務的執(zhí)行狀態(tài)在事務間的傳遞來控制分支事務的提交與回滾。文章來源：http://www.zghlxwxcb.cn/news/detail-482082.html
參考：《分布式事務》文章來源地址http://www.zghlxwxcb.cn/news/detail-482082.html
到了這里，關于聊聊什么是分布式事務的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
