大白話聊聊分散式事務

什麼是分散式事務

簡單的來說就是，一個大的操作由兩個或者更多的小的操作共同完成。而這些小的操作又分佈在不同的網路主機上。這些操作，要麼全部成功執行，要麼全部不執行。

拿轉賬的例子來說下什麼是分散式事務。張三和李四在不同的城市，儲存他們賬戶資訊的伺服器也在不同的網路主機上。張三有30元錢，李四有30元錢。張三給李四轉賬5元就是一個事務。完成這個事務，需要兩個操作。首先得從張三賬戶上扣5元，然後再給李四賬戶上加5元。事務執行完畢後，必須是兩個操作都執行成功，要麼都失敗。

事務的特性

分散式事務本身就是事務，所以也有事務的特性。事務有四個特徵ACID：
A：原子性（Atomicity）

事務中的各個操作單元要麼全部做，要麼就全部不做。不能事務執行後，處於只做一半的狀態。

C：一致性（Consistency）

事務執行後，必須由一個一致狀態變為另外一個一致狀態。

I：隔離性（Isolation）

事務之間不能相互干擾。

D：永續性（Durability）

一旦事務完成，對於資料的變更是永久的。

分散式事務實現方式

下面我們就以上面轉賬的例子來說下實現分散式事務的幾種方式。

兩階段提交

兩階段提交的大概流程：

第一階段：
正常情況下的操作過程如下：

在第一階段，主要是事務管理者（經理）發起事務，讓各個事務資源方（職員甲乙）確認資源是否滿足，並做預處理（凍結）。資源方的操作有可能失敗也可能成功。如，張三賬戶不足5元錢，沒辦法凍結，就是失敗。資源方把操作結果反饋給事務管理者。

異常情況下的操作過程如下：

如果預提交過程中出現任何問題，導致事務不能執行。將會通知資源方進行撤銷預提交操作。

第二階段：
如果是職員甲和職員乙都告訴經理，操作成功了。
正常情況下的操作過程如下：

這個時候，張三賬戶上的金額是25元。李四賬戶上的金額是35元。

異常情況下的操作過程如下：

這個時候，張三賬戶上的金額是30元。李四賬戶上的金額也是30元。

總而言之，事務的執行會分為預提交和提交兩步進行。任何一個小操作出問題，導致事務不能完成，將會進行回滾操作。

兩階段提交需要注意的

兩階段提交，要有一個事務管理者協調各方的操作。各方對資源的佔用要到整個事務結束後才能釋放。這樣會影響事務的效率。當併發量大的時候，系統的效能會嚴重下滑。

事務管理者和資源方存在通訊。有可能存在通訊不通暢。如，職員甲接受到扣錢的命令後，職員甲扣完了錢。由於電話故障等原因，導致沒辦法通知經理已經操作成功。因此，各方還要處理通訊超時問題。

整個流程需要事務管理者協調各個資源方進行操作。但是，事務管理者可能出現問題。導致沒辦法進行協調。如，經理生病了。

注意冪等性問題。可能存在對資源方重複呼叫的情況。這種情況下，資源方被呼叫多次和呼叫一次的效果要一樣。如上例中，經理第二次通知職員甲扣5元的時候，職員甲要像上次一樣，告訴經理扣款已經完成。但是，職員甲不能再進行扣款的動作。

基於訊息實現

基於訊息的實現大概過程如下：

基於訊息的分散式事務實現中，引入了訊息中介軟體（助理），負責訊息的傳遞和事務執行狀態的詢問。這樣就降低了系統間的耦合度。

為什麼職員甲在進行扣款前，要告訴助理？主要是怕自己扣款成功了，又忘記告訴助理。這個時候，助理也就沒辦法通知職員乙操作了。告訴助理後，如果職員甲忘記了，助理可以詢問職員甲，是否執行成功。進而決定是否該通知職員乙進行加錢操作。

如果職員甲扣款失敗，則應該通知助理。助理在這種情況下，就不英再通知職員乙加錢。

基於訊息實現的問題

基於訊息的分散式事務實現，講究的是最終一致性。也即所有的本地事務執行完畢後，整個狀態的一致。

整個事務一般不會有回滾操作。如，當職員乙操作失敗的時候，職員應該是再次通知職員乙重試。