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、需要注意整體的事務隔離問題。

             綜上：考慮到效能和複用方面，訊息佇列應該是最為理想的分散式事務解決方案。