分佈式服務-DUBBOX(九):多服務串行調用，解決分佈式事務問題

一、概述

情景描述：

    dubbo服務A：支付接口服務

    dubbo服務B：訂單狀態更新

正常流程，首先調用支付接口，支付成功後，再調用dubbo服務B更新訂單狀態；可是若是在調用dubbo服務B時失敗，此時dubbo服務A中數據已沒法回滾（事務已提交），此時該如何進行處理?

 

• 方案一：

    手動編寫dubbo服務A回滾代碼，在dubbo服務B調用失敗時，進行該回滾代碼調用，此方案只使用簡單業務場景、冗餘代碼多。

• 方案二：

    使用JTA分佈式事務，但這樣很差的就是代碼入侵性高以及性能問題。（本人也沒有用過，網上這麼講的）。

• 方案三：

    結合MQ消息中間件實現的可靠消息，來到達數據最終一致性（CAP理論）。

 

二、折中方案

    方案一不理想，方案2、三相關技術沒具體接觸過。

    下圖是項目中遇到的折中方案：

    也就是說「dubbo服務A」便是提供者也是消費者（dubbo服務B的調用），只有在"dubbo服務B"調用成功的狀況下才會對「dubbo服務A」事務提交。

    侷限：

• 便是生產者又是消費者的dubbo服務，只能進行「惟一」dubbo服務調用。
• 而這個「單一」dubbo服務調用只能放在最後執行。

三個服務調用狀況就是以下

 

三、收尾

    至此，關於分佈式服務框架-dubbo總結完畢！

     額外提下，以前demo工程中主鍵id採用的數據庫自增，在「分佈式」侷限性

• 分佈式服務中，重試機制下容易形成數據重複。
• 存在主外鍵依賴的狀況下，外鍵設值麻煩。
• 再也不適用於拆表拆庫。