概念：
分布式事務就是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不同的分布式系統的不同節點之上。以上是百度百科的解釋，簡單的說， 就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務器上，且屬於不同的應用，分布式事務需要保證這些小操作要么全部成功，要么全部失敗。 本質上來說，分布式事務就是為了保證不同數據庫的數據一致性。
分布式事務的應用場景：
事務必須滿足傳統事務的特性，即原子性，一致性，分離性和持久性。但是分布式事務處理過程中，
1. 當數據庫單表一年產生的數據超過1000W，那么就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以后有空詳細說，簡單的說就是原來的一個數據庫變成了多個數據庫。這時候，如果一個操作既訪問01庫，又訪問02庫，而且要保證數據的一致性，那么就要用到分布式事務。
2. 所謂的SOA化，就是業務的服務化。比如原來單機支撐了整個電商網站，現在對整個網站進行拆解，分離出了訂單中心、用戶中心、庫存中心。對於訂單中心，有 專門的數據庫存儲訂單信息，用戶中心也有專門的數據庫存儲用戶信息，庫存中心也會有專門的數據庫存儲庫存信息。這時候如果要同時對訂單和庫存進行操作，那 么就會涉及到訂單數據庫和庫存數據庫，為了保證數據一致性，就需要用到分布式事務。
另外還比如：
某些場地比如在電商系統中，當有用戶下單后，除了在訂單表插入一條記錄外，對應商品表的這個商品數量必須減1吧，怎么保證？
在搜索廣告系統中，當用戶點擊某廣告后，除了在點擊事件表中增加一條記錄外
事務的ACID特性
事務必須滿足傳統事務的特性，即原子性，一致性，分離性和持久性。
1. 所謂的原子性就是說，在整個事務中的所有操作，要么全部完成，要么全部不做，沒有中間狀態。對於事務在執行中發生錯誤，所有的操作都會被回滾，整個事務就像從沒被執行過一樣。
2. 事務的執行必須保證系統的一致性，就拿轉賬為例，A有500元，B有300元，如果在一個事務里A成功轉給B50元，那么不管並發多少，不管發生什么，只要事務執行成功了，那么最后A賬戶一定是450元，B賬戶一定是350元。
3. 所謂的隔離性就是說，事務與事務之間不會互相影響，一個事務的中間狀態不會被其他事務感知。
4. 所謂的持久性，就是說一單事務完成了，那么事務對數據所做的變更就完全保存在了數據庫中，即使發生停電，系統宕機也是如此。
常見解決方案：
1. 基於XA協議的兩階段提交
分布式事務通常采用2PC協議，全稱Two Phase Commitment Protocol。該協議主要為了解決在分布式數據庫場景下，所有節點間數據一致性的問題。分布式事務通過2PC協議將提交分成兩個階段：
1. prepare；
2. commit/rollback
階段一為准備（prepare）階段。即所有的參與者准備執行事務並鎖住需要的資源。參與者ready時，向transaction manager報告已准備就緒。
階段二為提交階段（commit）。當transaction manager確認所有參與者都ready后，向所有參與者發送commit命令。
2. 消息事務+最終一致性
所謂的消息事務就是基於消息中間件的兩階段提交，本質上是對消息中間件的一種特殊利用，它是將本地事務和發消息放在了一個分布式事務里，保證要么本地操作成功成功並且對外發消息成功，要么兩者都失敗
總結：
分布式事務，本質上是對多個數據庫的事務進行統一控制，按照控制力度可以分為：不控制、部分控制和完全控制。不控制就是不引入分布式事務，部分控制就是各 種變種的兩階段提交，包括上面提到的消息事務+最終一致性、TCC模式，而完全控制就是完全實現兩階段提交。部分控制的好處是並發量和性能很好，缺點是數 據一致性減弱了，完全控制則是犧牲了性能，保障了一致性，具體用哪種方式，最終還是取決於業務場景。作為技術人員，一定不能忘了技術是為業務服務的，不要 為了技術而技術，針對不同業務進行技術選型也是一種很重要的能力！