分散式交易 ：可靠訊息最終一致性方案

事務想必大家並不陌生，例如經常被人提起的ACID，但是為了後續的分佈式事務的內容，我們先來聊聊ACID，然後再介紹下什麼是分散式交易，最後著重講下基於可靠訊息的分散式事務解決方案。

什麼是事務

嚴格意義上的事務應該是具備原子性、一致性、隔離性和持久性，簡稱ACID。

1. 原子性（Atomicity），可以理解為一個事務內的所有操作要麼都執行，要麼都不執行。
2. 一致性（Consistency），可以理解為數據是滿足完整性限制的，也就是不會存在中間狀態的數據，例如你錢包有100 ，我錢包有100，你給我打50塊，此時你錢包的錢應該是50，我錢包的錢應該是150，不會存在我錢加了，你錢沒扣的中間狀態。
3. 隔離性（Isolation），指的是多個事務並發執行的時候不會互相干擾，即一個事務內部的資料對於其他事務來說是隔離的。
4. 持久性（Durability），指的是一個事務完成了之後資料就被永遠保存下來，之後的其他操作或故障都不會對事務的結果產生影響。

而通俗意義上事務就是為了使得一些更新操作要麼都成功，要麼都失敗。

什麼是分散式交易

分散式交易顧名思義就是要在分散式系統中實現事務，它其實是由多個本地事務組合而成。

一次大的操作由不同的小操作組成的，這些小的操作分佈在不同的伺服器上，分散式事務需要保證這些小操作要么全部成功，要么全部失敗。從本質上來說，分散式交易就是為了保證不同資料庫的資料一致性。

常見的分散式交易的解決方案有以下幾種:2PC,3PC,TCC,本地訊息表、可靠訊息最終一致性、盡最大努力通知等

今天我們就著重講講可靠訊息最終一致性的解決方案

什麼是可靠訊息最終一致性方案

可靠訊息最終一致性方案是指當事務發起方執行完成本地事務後發出訊息到訊息中介軟體，事務參與方(訊息消費者)一定能夠接收到訊息並處理事務成功，此方案強調的是只要訊息發給事務參與方，則最終事務要達到一致。

這個方式有哪些問題？

此方案是透過訊息中間件實現的，事務發起者（訊息生產方）將訊息發給訊息中間件，事務參與者從訊息中間件接收訊息，由於網路通訊的不確定性會導致分散式事務問題，如下圖：

1. #本地事務與訊息的原子性問題

#如上圖在虛線框內，存在以下幾種情況：

1）本地交易提交失敗，則訊息不發送。
2）本地事務成功，訊息發送失敗，本地事務回滾。
3）本地訊息成功，訊息逾時，本地事務回滾，訊息最終失敗。
4）本地訊息成功，訊息逾時，本地事務回滾，訊息最終成功。

綜上所述，存在著第四種情況，造成本地事務，與訊息參與者的事務不一致。

2. 事務參與方接收訊息的可靠性。
   

訊息中間件與事務參與方要確保能夠成功消費到訊息。

3. 訊息重複消費
   

注意事務參與方的介面冪等性問題，訊息參與者可能已經成功消費，由於網路問題導致訊息中間件認為訊息未消費，發起重試之後產生的問題。

解決方案

1. 本機訊息表
   

本機訊息表的關鍵在於本機有儲存訊息日誌的記錄表，需要啟動一個定時任務去不停地掃描訊息日誌記錄，確保訊息能夠被傳送。具體流程如下圖：

上圖流程：

1）事務發起方本地事務執行成功，在本地訊息表中記錄訊息日誌。
2）啟動定時任務，循環掃描本機訊息表。
3）定時任務掃描到訊息則傳送訊息到訊息中間件。
4）訊息中間件收到訊息，成功回傳訊息發送成功通知給事務發起方。
5）事務發起方收到訊息傳送成功則刪除日誌訊息。
6）事務參與者訂閱訊息，消費訊息。
7）事務參與方處理本地事務。
8）本地事務處理成功，發送成功ack給訊息中間件。

需要注意的點:
交易參與者保證介面冪等性。

2. RocketMq事務訊息方案
   

#Apache RocketMQ 4.3之後的版本正式支援交易訊息，為分散式事務實作提供了便利性支援。在RocketMQ 4.3後實現了完整的事務訊息，實際上其實是對本地訊息表的一個封裝，將本地訊息表移動到了MQ內部，解決Producer 端的訊息發送與本地事務執行的原子性問題。

實作流程：

1）事務發起者傳送Half交易訊息
2）RocketMq回覆Half傳送成功
3）事務發起方執行本地事務
4）事務發起方執行本地事務成功，發送commit到RocketMq，mq投遞訊息到事務參與方；事務發起方執行本地事務失敗，發送rollback到RocketMq，mq刪除訊息。
5）當RocketMq一定時間內未收到來自事務發起方的確認訊息，會對事務發起方進行事務回查。
6）事務發起方查詢本地事務狀態。
7）事務發起方根據查詢到的事務狀態發送commint/rollback到RocketMq。
8）當RocketMq發起commit後，收到失敗或一定時間未收到成功ack，則會發起重試。

優點：

訊息資料獨立存儲，降低業務系統與訊息系統之間的耦合。
吞吐量優於本機訊息表方案。

缺點：

一次訊息發送需要兩次網路請求(half訊息 commit/rollback)。
需要實作訊息回查介面。

其實每個分散式事務的解決方案都有優劣，我們需要權衡利弊，選擇最適合業務場景的一種才是王道！

#

以上是分散式交易 ：可靠訊息最終一致性方案的詳細內容。更多資訊請關注PHP中文網其他相關文章！