分佈式事務是什麼
先看看百度百科的解釋，分佈式事務是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不同的分佈式系統的不同節點之上。簡單來說就是
一個大的操作由兩個或者更多的小的操作共同完成。而這些小的操作又分佈在不同的網絡主機上。這些操作，要麼全部成功執行，要麼全部不執行。
PS：拿轉帳來說。張三和李四在不同的城市，存儲他們賬戶信息的服務器也在不同的網絡主機上。張三有30元錢，李四有30元錢。張三給李四轉賬5元就是一個事務。完成這個事務，需要兩個操作。首先得從張三賬戶上扣5元，然後再給李四賬戶上加5元。事務執行完畢後，必須是兩個操作都執行成功，要麼都失敗。
所以本質來說，分佈式事務就是為了保證不同數據庫的數據一致性。
分佈式事務的產生的原因
數據庫分庫分表
當數據庫單表一年產生的數據超過1000W，那麼就要考慮分庫分表，原來的一個數據庫變成了多個數據庫。這時候，如果一個操作既訪問01庫，又訪問02庫，而且要保證數據的一致性，這時候就要用到分佈式事務。
應用SOA化
也就是業務的服務化。比如原來單機支撐了整個電商網站，現在對整個網站進行拆解，分離出了訂單中心、用戶中心、庫存中心。對於訂單中心，有專門的數據庫存儲訂單信息，用戶中心也有專門的數據庫存儲用戶信息，庫存中心也會有專門的數據庫存儲庫存信息。這時候如果要同時對訂單和庫存進行操作，那麼就會涉及到訂單數據庫和庫存數據庫，為了保證數據一致性，就需要用到分佈式事務。
PS:其實就是要操作多個數據庫了。
事務的特性
分佈式事務本身就是事務，所以也有事務的特性。事務有四個特徵ACID：
A：原子性（Atomicity）
事務中的各個操作單元要麼全部做，要麼就全部不做。不能事務執行後，處於只做一半的狀態。
C：一致性（Consistency）
事務執行後，必須由一個一致狀態變為另外一個一致狀態。
I：隔離性（Isolation）
事務之間不能相互干擾。
D：持久性（Durability）
一旦事務完成，對於數據的變更是永久的。
分佈式事務實現方式
實現分佈式事務的幾種方式。
兩階段提交
第一階段：
正常情況下的操作過程如下：
在第一階段，主要是事務管理者（經理）發起事務，讓各個事務資源方（職員甲乙）確認資源是否滿足，並做預處理（凍結）。資源方的操作有可能失敗也可能成功。如，張三賬戶不足5元錢，沒辦法凍結，就是失敗。資源方把操作結果反饋給事務管理者。
異常情況下的操作過程如下：
如果預提交過程中出現任何問題，導致事務不能執行。將會通知資源方進行撤銷預提交操作。
第二階段：
如果是職員甲和職員乙都告訴經理，操作成功了。
這個時候，張三賬戶上的金額是25元。李四賬戶上的金額是35元。
這個時候，張三賬戶上的金額是30元。李四賬戶上的金額也是30元。
總而言之，事務的執行會分為預提交和提交兩步進行。任何一個小操作出問題，導致事務不能完成，將會進行回滾操作。
兩階段提交需要注意的
兩階段提交，要有一個事務管理者協調各方的操作。各方對資源的佔用要到整個事務結束後才能釋放。這樣會影響事務的效率。當併發量大的時候，系統的性能會嚴重下滑。
事務管理者和資源方存在通信。有可能存在通信不通暢。如，職員甲接受到扣錢的命令後，職員甲扣完了錢。由於電話故障等原因，導致沒辦法通知經理已經操作成功。因此，各方還要處理通信超時問題。
整個流程需要事務管理者協調各個資源方進行操作。但是，事務管理者可能出現問題。導致沒辦法進行協調。如，經理生病了。
注意冪等性問題。可能存在對資源方重複調用的情況。這種情況下，資源方被調用多次和調用一次的效果要一樣。如上例中，經理第二次通知職員甲扣5元的時候，職員甲要像上次一樣，告訴經理扣款已經完成。但是，職員甲不能再進行扣款的動作。
基於消息實現
基於消息的實現大概過程如下：
基於消息的分佈式事務實現中，引入了消息中間件（助理），負責消息的傳遞和事務執行狀態的詢問。這樣就降低了系統間的耦合度。
為什麼職員甲在進行扣款前，要告訴助理？主要是怕自己扣款成功了，又忘記告訴助理。這個時候，助理也就沒辦法通知職員乙操作了。告訴助理後，如果職員甲忘記了，助理可以詢問職員甲，是否執行成功。進而決定是否該通知職員乙進行加錢操作。
如果職員甲扣款失敗，則應該通知助理。助理在這種情況下，就不英再通知職員乙加錢。
基於消息實現的問題
基於消息的分佈式事務實現，講究的是最終一致性。也即所有的本地事務執行完畢後，整個狀態的一致。
整個事務一般不會有回滾操作。如，當職員乙操作失敗的時候，職員應該是再次通知職員乙重試。
閱讀更多 溫榆河大咖 的文章
