說是分布式事務，其實已經完全不是關系型數據庫的那種強一致性事務了。只能說最終數據一致性的解決方案。
方案1， 獨立消息 ：
解釋：獨立消息，如上圖，主動服務想發送一個消息給被動消費者。我們要保證消息不丟失。確保 主動 服務 和 被動消費者數據一致性。
主動服務發起一個預消息給 獨立的消息服務器，但是獨立消息服務器不是馬上把消息傳遞給 消費者。而是持久化到獨立消息服務器的 硬盤（ 數據庫 或者別的方式 都可以），只有等這個預消息被確認的時候才會投遞給消費方。
這時候主動服務的發送方法 繼續下面的 關聯邏輯。如果報錯，這個發送方法 回滾。如果正確執行，那么在提交事務之前 向 獨立消息服務器 確認前面發送的 預消息
（備注：要保證這個確認不會影響到事務的提交，確認方法不能拋出任何異常，但是也可以按需求回滾事務）。並且確認預消息那一步可不不執行。獨立消息服務 收到 確認以后 傳遞消息給 消費者。
假如主動服務事務回滾，那么這個方法的記錄都被回滾，預消息沒有被確認。獨立消息服務器的 確認預消息機制 會在稍后 向主動服務發起詢問。如果主動服務的數據回滾了，那么查詢不到任何記錄。這條預消息被丟棄。
如果主動事務完全了。但是確認請求忘了發，或者沒有發出去,獨立消息服務有主動詢問機制會詢問主動服務 怎么處理這個消息。
上面已經保證了主動服務的消息到 獨立消息服務 絕對不丟。后面是就是保證獨立消息服務到 消費者的絕對不丟。
備注：上圖的 mq 不是 必須的。我后面你的實現代碼用了 mq 。所以把它 畫圖上了。
消息確認需要發出一后。獨立消息服務向 消費者 發送消息。 持久的在硬盤中的這個條消息狀態改變，變成發送中。消費者收到消息處理完邏輯一后 。告訴獨立消息服務，正常接收，獨立消息服務 吧這條消息標記為完成。
如果消費者不告知獨立消息服務完成消息，那么 獨立消息服務的重發機制會再次向消費者發送這條消息。直到消費者正常確認收到這條消息。因為有重發，所以消費者可能重復處理這條消息，所以需要消費者 冪等 的處理這個消息的后續邏輯。
明顯上面的過程數據傳遞可靠性極高。理論上100% 的不丟消息，但是明顯的依賴嚴重，雖然獨立消息服務 是一個獨立運行，自帶詢問，自帶重發的 ，和主動服務 被動消費者 無關的獨立程序。但是 依舊需要主動 服務實現大量的詢問接口 。（被動消費者的確認接口只有一個不是問題），
獨立消息類型的代碼實現：https://github.com/hualiuwuxin/reliable-message.git
方案2:最大努力通知型：
解釋：支付回調就是這種模式。上面圖中 mq 也不是必須的。但是一般會用。如果仔細看的朋友會發現，這個就是 獨立消息服務 消息確認發送 后 到 消費者的流程的一個變種。
主動方吧消息告訴通知服務（這個過程可以通過 獨立消息，可以通過事務存儲等方法保證一致性），現在通知服務 已經拿到的 這個消息。並且存儲了。通知服務發送消息給
被通知方，如果被通知方正確的返回，那么這個消息標記為完成。如果這個消息發送失敗，那么這個消息上面標記發從次數+1，並且過一會再發送，直到被通知正確的返回，
或者發送次數超過限制。盡力的通知 對方了，但是實在通知不到就不通知了，但是提供查詢接口，在對方想要直到結果的時候能夠查詢到這個消息。
最大努力通知型適合 跨公司之間的交互。但是需要被動主動查詢才能保證數據100% 的一致性。
方案3：本地消息型：
解釋：這個本地消息就簡單很多了，它是獨立消息的一個變種。消息存在本地數據庫中，簡化了消息發送的詢問過程。但是 主動服務 和 消費服務之間的關聯更加密切。並且不再通用。但是實現變得簡單了。（上圖的mq也不是必須的）
主動服務的業務變更存在本地數據庫中，然后把被動數據庫的數據變更也存到本地消息部分的數據庫中，這個兩個保存在一個事務中，在這個事務提交前 發送消息數據給 消費者（備注，這個發送方法可以發送失敗，但是不能拋出異常）
這時候本地消息狀態是發送中，如果 消費方 正常的 處理 了消息數據，告訴 主動方，主動方的這條消息標記為 完成。如果 消費方 沒有正常的響應 ，那么重發 機制 會重發那這條消息。
因為消息有重發，可能重復處理，所以要求消費方冪等的處理 消息數據