大白話聊聊分布式事務
什么是分布式事務
簡單的來說就是，一個大的操作由兩個或者更多的小的操作共同完成。而這些小的操作又分布在不同的網絡主機上。這些操作，要么全部成功執行，要么全部不執行。
拿轉賬的例子來說下什么是分布式事務。張三和李四在不同的城市，存儲他們賬戶信息的服務器也在不同的網絡主機上。張三有30元錢，李四有30元錢。張三給李四轉賬5元就是一個事務。完成這個事務，需要兩個操作。首先得從張三賬戶上扣5元，然后再給李四賬戶上加5元。事務執行完畢后，必須是兩個操作都執行成功，要么都失敗。
事務的特性
分布式事務本身就是事務，所以也有事務的特性。事務有四個特征ACID：
A：原子性（Atomicity）
事務中的各個操作單元要么全部做，要么就全部不做。不能事務執行后，處于只做一半的狀態。
C：一致性（Consistency）
事務執行后，必須由一個一致狀態變為另外一個一致狀態。
I：隔離性（Isolation）
事務之間不能相互干擾。
D：持久性（Durability）
一旦事務完成，對于數據的變更是永久的。
分布式事務實現方式
下面我們就以上面轉賬的例子來說下實現分布式事務的幾種方式。
兩階段提交
兩階段提交的大概流程：
第一階段：
正常情況下的操作過程如下：
在第一階段，主要是事務管理者（經理）發起事務，讓各個事務資源方（職員甲乙）確認資源是否滿足，并做預處理（凍結）。資源方的操作有可能失敗也可能成功。如，張三賬戶不足5元錢，沒辦法凍結，就是失敗。資源方把操作結果反饋給事務管理者。
異常情況下的操作過程如下：
如果預提交過程中出現任何問題，導致事務不能執行。將會通知資源方進行撤銷預提交操作。
第二階段：
如果是職員甲和職員乙都告訴經理，操作成功了。
正常情況下的操作過程如下：
這個時候，張三賬戶上的金額是25元。李四賬戶上的金額是35元。
異常情況下的操作過程如下：
這個時候，張三賬戶上的金額是30元。李四賬戶上的金額也是30元。
總而言之，事務的執行會分為預提交和提交兩步進行。任何一個小操作出問題，導致事務不能完成，將會進行回滾操作。
兩階段提交需要注意的
兩階段提交，要有一個事務管理者協調各方的操作。各方對資源的占用要到整個事務結束后才能釋放。這樣會影響事務的效率。當并發量大的時候，系統的性能會嚴重下滑。
事務管理者和資源方存在通信。有可能存在通信不通暢。如，職員甲接受到扣錢的命令后，職員甲扣完了錢。由于電話故障等原因，導致沒辦法通知經理已經操作成功。因此，各方還要處理通信超時問題。
整個流程需要事務管理者協調各個資源方進行操作。但是，事務管理者可能出現問題。導致沒辦法進行協調。如，經理生病了。
注意冪等性問題。可能存在對資源方重復調用的情況。這種情況下，資源方被調用多次和調用一次的效果要一樣。如上例中，經理第二次通知職員甲扣5元的時候，職員甲要像上次一樣，告訴經理扣款已經完成。但是，職員甲不能再進行扣款的動作。
基于消息實現
基于消息的實現大概過程如下：
基于消息的分布式事務實現中，引入了消息中間件（助理），負責消息的傳遞和事務執行狀態的詢問。這樣就降低了系統間的耦合度。
為什么職員甲在進行扣款前，要告訴助理？主要是怕自己扣款成功了，又忘記告訴助理。這個時候，助理也就沒辦法通知職員乙操作了。告訴助理后，如果職員甲忘記了，助理可以詢問職員甲，是否執行成功。進而決定是否該通知職員乙進行加錢操作。
如果職員甲扣款失敗，則應該通知助理。助理在這種情況下，就不英再通知職員乙加錢。
基于消息實現的問題
基于消息的分布式事務實現，講究的是最終一致性。也即所有的本地事務執行完畢后，整個狀態的一致。
整個事務一般不會有回滾操作。如，當職員乙操作失敗的時候，職員應該是再次通知職員乙重試。
