分布式事務方案 - SAGA模式

2020-11-13 閃念基因

作者:杜亦舒

來源:微信公眾號:性能與架構

出處:https://mp.weixin.qq.com/s?__biz=MzA4Nzc4MjI4MQ==&mid=2652404032&idx=1&sn=f3e7d518e7cbbe797d4eefbf355e27da


本文目的是講清楚 SAGA 這種分布式事務解決方案的實現思路，不包括具體實現代碼，具體實現推薦使用阿里的Seata 框架。

內容包括：

  • 分布式事務問題描述
  • SAGA - Choreography 策略
  • SAGA - Orchestration 策略

補充：

常用的分布式事務解決方案還包括TCC、 可靠消息模式 。

1. 分布式事務問題描述

比如說電商系統中，用戶下單了，後端需要調用：

  • 訂單服務，創建訂單
  • 庫存服務，改商品的庫存
  • 物流服務，創建物流單，準備發貨

在分布式的微服務架構中，每個服務都會有自己獨立的資料庫，那麼，這個下單的動作就涉及到了向多個資料庫中寫入數據。

因為不是在同一個資料庫中，所以就不能依賴資料庫的事務機制了，但是在業務邏輯中，這幾個寫庫操作就應該是一個事務。

比如訂單服務、庫存服務中都寫入成功了，但物流系統出現異常了，那麼訂單服務、庫存服務就應該進行回滾，來保證整體數據的一致性。

如何在跨資料庫的情況下實現事務呢？這就是分布式事務問題。

SAGA 就是一種老牌的分布式事務解決方案，已經有20來年了，其實現方式主要有兩種：

  • Choreography
  • Orchestrator

下面介紹一下各自的實現思路。

2. SAGA - Choreography 策略

Choreography 是編舞的意思，就是把舞者之間的動作配合都編排好。

對應到分布式事務，就可以把各個服務理解為舞者，SAGA 的 Choreography 策略就是要定義好先執行哪個服務，根據執行結果再觸發哪些服務的執行。

如上圖，整體分布式事務處理流程為：

  1. 訂單服務寫自己的業務數據，並在資料庫中 記錄 一下訂單的整體 狀態 ，比如記為 "已下單"。
  2. 訂單服務發布【訂單創建成功】事件，庫存服務會監聽此事件。
  3. 庫存服務收到事件通知後，寫自己的業務數據，然後發布【庫存修改成功】事件。
  4. 訂單服務會監聽此事件，收到事件通知後，修改訂單狀態，比如 "待發貨"。
  5. 物流服務也會監聽此事件，收到事件通知後，寫自己的業務數據，然後發布【物流處理成功】。
  6. 訂單服務會監聽此事件，收到通知後，修改訂單狀態，改為 "已發貨"。

這樣，通過事件機制，各個服務之間完成協同配合，實現了分布式事務。

下面看異常情況的處理，比如物流服務異常了，如下圖。

重點看異常處理流程：

  1. 物流服務會發布事件【物流處理異常】。
  2. 訂單服務、庫存服務都監聽此事件，所以會收到物流異常的通知。圖中（8）、（9）。
  3. 訂單服務執行自己的回滾邏輯。圖中（10）。
  4. 庫存服務執行自己的回滾邏輯。圖中（11）。

這樣就實現了分布式事務的異常處理。

SAGA Choreography 策略是通過【事件機制】實現的，各個服務都定義好正常、異常的處理方法，然後監聽目標事件，根據不同的事件來調用不同的處理方法。

此策略好處是實現簡單，壞處是整體事件邏輯會比較複雜，比如有10個服務參與其中，那麼整體事件訂閱關係就會很凌亂。

3. SAGA - Orchestration

Orchestration 是樂隊編排的意思。

對應到分布式事務，各個服務就是樂隊中的各個演奏者，還需要一個【總指揮】，所以在 SAGA - Orchestration 策略中會單獨創建一個此角色。

![image-20201111184654838](/Users/a/Library/Application Support/typora-user-images/image-20201111184654838.png)

如上圖，正常處理流程：

  1. 訂單服務寫自己的業務數據
  2. 訂單服務向總指揮報告自己完成了
  3. 總指揮向庫存服務發送執行指令
  4. 庫存服務寫數據
  5. 庫存服務報告自己完成了
  6. 總指揮向訂單服務發送指令
  7. 訂單服務更新訂單狀態
  8. 總指揮向物流服務發送指令

......

後面的就不細說，都是一個思路。

異常處理的思路也是一樣的，還是假設物流服務異常了，那麼它會向總指揮報告，總指揮就會向訂單服務、庫存服務發送回滾的指令。

所以 Orchestration 策略的重點在於總指揮，需要為其定義指揮手冊，以便總指揮在不同的時刻向相應的服務發送對應的指令。

這個總指揮實際上是通過【狀態機】來實現的。

此策略好處是服務之間沒有關聯了，整體結構清晰。壞處是都了一個總指揮的角色，增加了複雜度。

4. 小結

Choreography 策略是通過事件機制實現的，每個服務都監聽自己所關心的事件，每個服務執行後會發送相應的事件，監聽此事件的服務執行相應的處理邏輯。

Orchestration 是通過狀態機來實現的整體控制，定義整體的處理流程，不同狀態下需要觸發的動作。


作者:杜亦舒

來源:微信公眾號:性能與架構

出處:https://mp.weixin.qq.com/s?__biz=MzA4Nzc4MjI4MQ==&mid=2652404032&idx=1&sn=f3e7d518e7cbbe797d4eefbf355e27da

相關焦點

  • 分布式事務的七種實現方案匯總
    那麼為什麼說該方案無法保證一致性和隔離性呢？由下圖可知，本地事務執行提交成功之後，才會對消息進行確認，而這個時候，遠程事務還未提交，一致性顯然無法滿足。我們知道，資料庫的隔離性是通過鎖機制來保證的，因而基於可靠消息服務的分布式事務方案要想滿足隔離性，往往還需要在事務發起方採用分布式鎖機制。因而總的來說，基於可靠消息服務的分布式方案適用於對業務的實時一致性以及事務的隔離性要求都不高的內部系統。
  • 5種分布式事務解決方案優缺點對比
    Basically Available（基本可用） Soft state（軟狀態） Eventually consistent（最終一致性）解決方案01 兩階段提交（2PC）兩階段提交2PC是分布式事務中最強大的事務類型之一，兩段提交就是分兩個階段提交，第一階段詢問各個事務數據源是否準備好，第二階段才真正將數據提交給事務數據源
  • 阿里Seata框架,多年雙十一歷練，無侵入式微服務分布式事務方案
    Seata 是一款開源的分布式事務解決方案，致力於提供高性能和簡單易用的分布式事務服務。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務模式，為用戶打造一站式的分布式解決方案。作者總結：1、其中AT模式對代碼完全沒有侵入性，你只需要一個@GlobalTransaction就可以實現分布式事務，TCC模式也同樣使用3個註解就可以搞定，SAGA模式阿里還給我們提供了可視化的狀態機編輯器。
  • 最全的分布式事務總結
    事務的定義 22． 資料庫本地事務四大特性 ACID 23． mysql InnoDB 實現原理 24． 什麼是分布式事務 35． 分布式事務產生的原因 46． 分布式事務的基礎理論 47． 分布式事務協議 58． 分布式常用解決方案 79．
  • 如何選擇分布式事務解決方案?
    阿里妹導讀：分布式事務中涉及的參與者分布在異步網絡中，參與者通過網絡通信來達到分布式一致性，網絡通信不可避免出現失敗、超時的情況，因此分布式事務的實現比本地事務面臨更多的困難。本文歸納總結五種分布式事務解決方案，並剖析其特點。較長，同學們可收藏後再看。文末福利：Java 程式設計師學習清單。
  • 這樣理解分布式事務你是不是就會懂了？
    Seata 會有 4 種分布式事務解決方案，分別是 AT 模式、TCC 模式、Saga 模式和 XA 模式。AT 模式AT 模式是一種無侵入的分布式事務解決方案。在 AT 模式下，用戶只需關注自己的「業務 SQL」，用戶的 「業務 SQL」 作為一階段，Seata 框架會自動生成事務的二階段提交和回滾操作。
  • 「技術貼」微服務中臺技術解析之分布式事務方案和實踐
    設計目標我們考慮通過引入一套分布式事務方案，達成以下各項設計目標：事務性提交：即ACID中的Atomicity。另一方面，Kafka 作為一個強大的隊列解決方案，它的眾多特性給分布式事務的設計和實現帶來了新的機遇和挑戰。
  • 基於RabbitMQ消息隊列的分布式事務解決方案
    、對帳單的形式; ● 基於可靠消息(MQ)的解決方案 異步場景;通用性較強;拓展性較高 ● TCC編程式解決方案 嚴選、阿里、螞蟻金服自己封裝的DTX 本文目標:針對所有人群，學會基於可靠消息來解決分布式事務問題。
  • 分布式事務消息隊列解決方案
    因為B如果失敗了,C是不應該提交的3.如果在A和B方法後面加上通知C的消息也不行，因為如果A,B一起提交失敗了,那麼C也是不應該通知的4.把A和B放在同一個方法裡面,把通知C的放在一個方法裡面,A,B提交了之後再通知C是否可行呢5.其實也是不行的,因為通知C可能會失敗啊,如果發送的通知失敗了,也是個問題6.所以把通知放在A,B之前,先發送一個事務消息到
  • BeetlSQL 3.1.0 發布,Spring Saga 事務支持
    本次發布增強了Saga在spring下的支持，使用kafka提供重試以及重試失敗後放入丟棄隊列裡Saga是用來在微服務中的長事務管理，具備ACID中的ACD，不具備I，隔離性。
  • 微服務架構下分布式事務解決方案——阿里GTS
    而對於第二個問題，現在還沒有通用方案很好的解決微服務產生的事務問題。分布式事務已經成為微服務落地最大的阻礙，也是最具挑戰性的一個技術難題。 為此，本文將深入和大家探討微服務架構下，分布式事務的各種解決方案，並重點為大家解讀阿里巴巴提出的分布式事務解決方案----GTS。
  • 開源分布式事務解決方案-Seata,1.0.0版正式發布
    題圖 from pixabay什麼是分布式事務分布式事務就是指事務的參與者、支持事務的伺服器、資源伺服器以及事務管理器分別位於不同的分布式系統的不同節點之上。簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的伺服器上，且屬於不同的應用，分布式事務需要保證這些小操作要麼全部成功，要麼全部失敗。
  • 分布式事務解決方案常見誤區與實用建議
    前言最近，工作中要為現在的老系統做拆分和升級，剛好遇到了分布式事務、冪等控制、異步消息亂序和補償方案等問題，剛好基於實踐結合個人的看法記錄一下一些方案和思路。因此，個人認為事務中直接RPC調用達到強一致性是完全不可取的，如果使用了這種方式實現"分布式事務"建議整改，否則只能每天祈求下遊服務或者網絡不出現任何問題。
  • 分布式事務：從理論到實踐（二）
    前文我們提到了Seata的AT和TCC模式，本文中我們針對這兩個模式進行深入分析和開發實踐。AT 模式原理回顧根據 官方文檔 及提供的 博客 我們先回顧一下AT模式下分布式事務的原理AT 模式的一階段、二階段提交和回滾均由 Seata 框架自動生成，用戶只需編寫「業務 SQL」，便能輕鬆接入分布式事務
  • 分布式事務框架Seata之AT模式
    Seata 是一款開源的分布式事務解決方案，致力於在微服務架構下提供高性能和簡單易用的分布式事務服務。在 Seata 開源之前，Seata 對應的內部版本在阿里經濟體內部一直扮演著分布式一致性中間件的角色，幫助經濟體平穩的度過歷年的雙11，對各BU業務進行了有力的支撐。經過多年沉澱與積累，商業化產品先後在阿里雲、金融雲進行售賣。
  • 後端程式設計師必備:分布式事務基礎篇
    簡單來說，分布式事務指的就是分布式系統中的事務，它的存在就是為了保證不同資料庫節點的數據一致性。為什麼需要分布式事務？接下來分兩方面闡述：微服務架構下的分布式事務隨著網際網路的快速發展，輕盈且功能劃分明確的微服務，登上了歷史舞臺。
  • Dubbo整合Seata，教你輕鬆實現TTC模式分布式事務
    SeataSeata 是一款開源的分布式事務解決方案，致力於提供高性能和簡單易用的分布式事務服務Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務模式，為用戶打造一站式的分布式解決方案。
  • 深入理解分布式事務
    1、什麼是分布式事務分布式事務就是指事務的參與者、支持事務的伺服器、資源伺服器以及事務管理器分別位於不同的分布式系統的不同節點之上。以上是百度百科的解釋，簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的伺服器上，且屬於不同的應用，分布式事務需要保證這些小操作要麼全部成功，要麼全部失敗。本質上來說，分布式事務就是為了保證不同資料庫的數據一致性。
  • 阿里終面：分布式事務原理
    分布式系統中常用的分布式事務解決方案，這些解決方案可以保證業務代碼在操作多個數據源的時候，能夠像操作單個數據源一樣，具備 ACID 特性。常見分布式事務解決方案2.1.這很難滿足電商等高並發場景對事務吞吐量的要求，因此網際網路服務提供商探索出了很多與 XA 協議背道而馳的分布式事務解決方案。其中利用消息中間件實現的最終一致性全局事務就是一個經典方案。
  • 基於MQ的分布式事務方案，斷電了咋辦
    涉及到分布式、微服務，面試一定會問分布式事務的處理方案，強一致性這種就不說了，很好奇現在是否還有企業在分布式系統中使用強一致性。最終一致性的實現，例如2PC、TCC本文就不說了，性能上，實現成本上都不理想。我從工作中以及跟朋友交流接觸到的消息來看，採用MQ較多。這就衍生出一個被問到很多次的問題：給MQ發消息失敗了怎麼辦，例如MQ伺服器斷電了。