從雙11業務看分布式事務滿足Saga和異步場景的示例分析

這篇文章給大家介紹從雙11業務看分布式事務滿足Saga和異步場景的示例分析，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

在雙11的時候，很多電商都在搞促銷，包括京東。

我們以大魏的書舉例，例如雙11的時候，買書除了打折好有紅包，這樣，買書的時候雙重優惠，如下圖所示：

那么，在雙11的場景中，買書的一次請求，就包括同步和異步的場景，如下圖所示。

同步場景采用Saga、異步場景采取事務消息（Sagas+本地事務消息表）。也就是說，分布式事務的設計要能同時滿足同步和異步兩種場景：

那么，我們看一次成功的雙11購物請求。

下圖的1、2、3、4是的是步驟，分別調用上圖的A、B、C、D應用模塊。

在上圖中，我們從App發起請求，請求被分配到任意一個網關層，再被分配到任意一個業余邏輯層。

1.業務邏輯層會先調用商品數據源訪問層進行減庫存（訪問DB)

2.第1步成功后，業務邏輯層訪問訂單數據訪問層，進行創建訂單本地事務(訪問

DB)，在下訂單的同時，業務邏輯層會向MQ發送延遲訂單支付消息，即事務消息。

3.第2步執行成功后，業務邏輯層調用紅包數據訪問層，進行減紅包操

(訪問DB）。成功后，紅包數據訪問會返回成功信息給交易邏輯層、交易邏輯層返回成功信息給網網關層、網關層返回信息給App。

4.App頁面自動跳轉到支付頁面，即業務邏輯層調用支付數據訪問層，進行前臺支付。

然后，整個操作完成。

那么，MQ中的訂單支付消息呢？當延遲支付消息到了超時時間后（京東是24小時），MQ的訂單延遲支付消息會被發到到業務邏輯層（因為業務邏輯層訂閱了MQ的Topic），然后業務邏輯層根據事務組表，判斷訂單有沒有支付，如果支付了，則直接刪除延遲消息。如果訂單未支付，則將事務組表中的state由1改成3（失敗）：

然后TM根據事務調用表，TM觸發事務補償：將紅包加回去、訂單+1、刪除訂單。

最后，Proxy將事務組表中的state由1改成4（補償成功）

那么，我們審視一下上圖的架構，在超高請求到來時，可能的瓶頸點在哪？

從技術架構來看，網關、交易業務邏輯層、數據訪問層都是無狀態的，可以橫向擴展，不存在瓶頸。對于DB而言，可以做數據分表。對于MQ而言，可以做分片。看起來也不存在性能瓶頸。

那么，為什么雙11的時候，在京東購物，還會發生購物失敗的情況呢？

原因是存在熱點數據，也就是特別搶手的貨物，例如：

如果要解決熱點數據問題，就需要做熱點數據預測。要做熱點數據預測，要先做異步化。也就是說，對于熱點緊俏商品的購買請求，直接先發到MQ中。然后再依次執行業務邏輯。

在這時，熱點就會被壓在MQ上。這時候，我們就需要對MQ做分片，但對于一個商品的一條記錄，我們如何對它做分片呢？可以加一列Type，把數據一行變多行：

然后我們可以把每一行記錄存在一個MQ的Topic中，就能消除熱點數據。

既然技術上熱點數據能夠消除，為啥雙11京東購物還有失敗呢？因為采購服務器是要花錢的，雙11電商會保證交易成功率，但這個成功率不會是100%，這是從ROI的角度去考慮的問題。

總結：在設計業務架構時，考慮到超高并發流量請求，我們需要注重架構如下三個方面：

關于從雙11業務看分布式事務滿足Saga和異步場景的示例分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。