叢集與負載均衡系列(7)——訊息佇列之分散式事務
XA協議:
為了解決分散式事務,各大廠家資料庫都提供了xa協議介面。什麼是XA協議,就是通過多階段提交,確保資料一致性。以兩階段提交為例
第一階段為準備階段,事務管理器會給每個資源管理器傳送Prepare訊息。每個資源管理器要麼返回失敗,要麼寫本地事務,redo和undo日誌寫好,但是不提交。
第二階段為提交階段,如果事務管理器收到任何資源管理器的失敗訊息或者超時訊息,會給每個資源管理器傳送回滾訊息。否則給每個資源管理器傳送提交訊息。
優點
2、sqlserver、oracle、mysql、db2都實現了該介面。
缺點:1、對於高併發應用,效能不夠理想。對於內網企業級應用是完全可以的。目前在內網中使用atmikos完全沒問題。
2、不是所有資料庫都實現了該介面,而且大部nosql都未實現該介面。
3、mysql主備切換時會導致資料不一致。
TCC程式設計模式
該模式是這樣的,try階段操作本地事務對資料庫A讀寫,成功則提交事務,失敗則回滾。confirm階段操作本地事務對資料庫B讀寫,成功則提交事務,失敗則進入cancel階段。cancel階段對資料庫A做逆操作。
優點:1、沒有鎖太多資源,效率可以。
缺點:1、由於與業務耦合,不好複用。
2、需要注意整體的事務隔離問題。
訊息佇列
比如之前提到的rabbitmq。思路是這樣的,操作本地事務對資料庫A讀寫,成功則提交事務,失敗則回滾。事務提交成功後,傳送可靠的訊息到訊息佇列服務,消費端操作本地事務對資料庫B讀寫,如果失敗則回滾並重新入隊。
可以看出來,這裡的關鍵就是可靠的訊息,就是訊息不能丟失,消費端必須成功消費。這就依賴於嚴格的測試,對於測試後漏網的bug來說,還有最後一道壁壘,就是在始終無法消費的時候發訊息通知管理員,進行手動處理。
優點:1、本來訊息佇列就是用來處理高併發的,效能不錯。
2、可以做到與業務解耦。
缺點:1、需要嚴格測試,保證各個環節的可靠性。
2、實現在三個方案裡面最為複雜。
3、需要注意整體的事務隔離問題。
綜上:考慮到效能和複用方面,訊息佇列應該是最為理想的分散式事務解決方案。