Saga 設計模式藉由協調多個服務之間的交易，協助維護分散式系統中的數據一致性。 傳奇是一連串的本機交易，其中每個服務都會執行其作業，並透過事件或訊息起始下一個步驟。 如果序列中的步驟失敗，saga 會執行補償交易，以復原完成的步驟。 這種方法有助於維護數據一致性。
內容和問題
交易 代表可包含多個作業的工作單位。 在交易中，事件 是指影響實體的狀態變更。 命令 封裝執行動作或觸發後續事件所需的所有資訊。
交易必須遵循不可部分完成性、一致性、隔離和持久性 （ACID） 的原則。
- 不可部分完成性： 所有作業都成功或沒有作業成功。
- 一致性： 數據會從一個有效狀態轉換成另一個有效狀態。
- 隔離： 並行交易會產生與循序交易相同的結果。
- 持久性：即使發生失敗， 變更在認可之後仍會保存。
在單一服務中，交易會遵循 ACID 原則，因為它們會在單一資料庫內運作。 不過，在多個服務之間達成 ACID 合規性可能更為複雜。
微服務架構中的挑戰
微服務架構通常會將 專用資料庫指派給每個微服務。 此方法提供數個優點：
- 每個服務都會封裝自己的數據。
- 每個服務都可以針對其特定需求使用最適合的資料庫技術和架構。
- 每個服務的資料庫都可以獨立調整。
- 一個服務中的失敗會與其他服務隔離。
儘管有這些優點，但此架構會使跨服務數據一致性複雜化。 傳統資料庫保證，例如 ACID 無法直接適用於多個獨立管理的數據存放區。 由於這些限制，依賴進程間通訊的架構，或傳統交易模型，例如兩階段認可通訊協定，通常更適合Saga模式。
溶液
Saga 模式會將交易分成一連串 本機交易，來管理交易。
每個本機交易：
- 在單一服務內以不可部分完成的工作。
- 更新服務的資料庫。
- 透過事件或訊息起始下一個交易。
如果本機交易失敗，saga 會執行一系列 補償交易， 來反轉先前本機交易所做的變更。
Saga 模式中的重要概念
補償交易 可以復原或補償其他具有相反效果的交易。 如果傳奇中的步驟失敗，補償交易會復原可補償交易所做的變更。
樞紐交易 做為傳奇中沒有傳回的點。 樞紐交易成功之後，可補償的交易就不再相關。 系統必須完成所有後續的動作，才能達到一致的最終狀態。 根據傳奇的流程，樞紐交易可以承擔不同的角色：
無法復原或重試不可復原或不可編譯的交易， 無法復原或重試。
可逆和認可的 之間的界限表示樞紐交易可以是最後一個可復原或可補償的交易。 或者，它可以是傳奇中的第一個可重試作業。
可重試的交易 遵循樞紐交易。 可重試的交易具有等冪性，且有助於確保傳奇事件可以達到其最終狀態，即使發生暫時性失敗也一樣。 他們幫助傳奇最終達到一致的狀態。
Saga 實作方法
這兩個典型的傳奇實作方法是 編舞 和 協調流程。 每個方法都有自己的一組挑戰和技術來協調工作流程。
編舞
在編舞方法中，服務會在沒有集中式控制器的情況下交換事件。 透過編舞，每個本機交易都會發佈網域事件，以在其他服務中觸發本機交易。
| 編舞的優點 | 編舞的缺點 |
|---|---|
| 適用於少數服務且不需要協調邏輯的簡單工作流程。 | 當您新增步驟時，工作流程可能會造成混淆。 很難追蹤每個傳奇參與者回應的命令。 |
| 協調不需要其他服務。 | 傳奇參與者之間有迴圈相依性的風險，因為它們必須取用彼此的命令。 |
| 不會引入單一失敗點，因為責任會分散到傳奇參與者。 | 整合測試很困難，因為所有服務都必須執行以模擬交易。 |
配器
在協調流程中，集中式控制器或 協調器，會處理所有交易，並告知參與者根據事件執行哪些作業。 協調器會執行傳奇要求、儲存和解譯每個工作的狀態，並使用補償交易處理失敗復原。
| 協調流程的優勢 | 協調流程的缺點 |
|---|---|
| 更適合複雜的工作流程，或當您新增服務時。 | 其他設計複雜度需要協調邏輯的實作。 |
| 避免迴圈相依性，因為協調器會管理流程。 | 引進失敗點，因為協調器會管理完整的工作流程。 |
| 清楚區分責任可簡化服務邏輯。 |
問題和考慮
當您決定如何實作此模式時，請考慮下列幾點：
設計思維轉變： 採用傳奇模式需要不同的心態。 它需要您專注於跨多個微服務的交易協調和數據一致性。
偵錯傳奇的複雜性： 偵錯傳奇可能相當複雜，特別是隨著參與服務數目的增長。
不可復原的本機資料庫變更：無法回復 數據，因為傳奇參與者會將變更認可至其各自的資料庫。
處理暫時性失敗和等冪： 當重複相同的作業不會改變結果時，系統必須有效處理暫時性失敗並確保等冪性。 如需詳細資訊，請參閱 等冪訊息處理。
監視和追蹤傳奇的需求： 監視和追蹤傳奇的工作流程是維護作業監督的重要工作。
補償交易的限制： 補償交易可能不一定成功，這可能會使系統處於不一致的狀態。
傳奇中潛在的數據異常
數據異常是當傳奇跨多個服務運作時可能發生的不一致。 因為每個服務都會管理自己的數據，稱為 參與者數據，因此不會跨服務進行內建隔離。 此設定可能會導致數據不一致或持久性問題，例如部分套用的更新或服務之間的衝突。 一般問題包括：
遺失的更新： 當某個傳奇修改數據而不考慮另一個傳奇所做的變更時，會導致覆寫或遺失更新。
Dirty 讀取： 當傳奇或交易讀取另一個傳奇已修改的數據時，但修改尚未完成。
模糊或不可重複讀取： 當傳奇中的不同步驟讀取不一致數據時，因為讀取之間發生更新。
解決數據異常的策略
若要減少或防止這些異常狀況，請考慮下列對策：
語意鎖定： 當傳奇交易的可補償交易使用旗號來指出更新正在進行時，請使用應用層級鎖定。
通勤更新： 設計更新，以便依任何順序套用更新，同時仍產生相同的結果。 這種方法有助於減少傳奇之間的衝突。
悲觀檢視： 重新排序傳奇的序列，讓數據更新在可重試的交易中發生，以消除骯髒的讀取。 否則，一個傳奇可以讀取髒數據，或 未認可的變更，而另一個傳奇同時執行可補償的交易來回復其更新。
重新讀取值： 確認數據在您進行更新之前會維持不變。 如果數據變更，請停止目前的步驟，並視需要重新啟動傳奇。
版本檔案： 維護記錄上執行之所有作業的記錄檔，並確保它們是以正確的順序執行，以防止衝突。
以風險為基礎的並行存取值： 根據潛在商務風險動態選擇適當的並行機制。 例如，針對低風險更新使用sagas，以及針對高風險更新使用分散式交易。
使用此模式的時機
當下列情況時，請使用此模式：
- 您必須確保分散式系統中的數據一致性，而不需要緊密結合。
- 如果序列中的其中一個作業失敗，您需要復原或補償。
當下列情況時，此模式可能不適合：
- 交易緊密結合。
- 補償交易發生在先前的參與者中。
- 有迴圈相依性。
下一步
相關資源
當您實作此模式時，下列模式可能相關：
編舞模式 讓系統的每個元件都參與商務交易工作流程的決策程式，而不是依賴控制中心點。
補償交易模式 復原一系列步驟所執行的工作，並在一或多個步驟失敗時最終定義一致的作業。 實作複雜商務程式和工作流程的雲端裝載應用程式通常會遵循此 最終一致性模型。
重試模式 可讓應用程式透過透明重試失敗的作業，來處理暫時性失敗。 此模式可以改善應用程式的穩定性。
斷路器模式 處理當您連線到遠端服務或資源時，需要一段時間才能復原的錯誤。 此模式可以改善應用程式的穩定性和復原能力。
健全狀況端點監視模式 實作應用程式中的功能檢查，外部工具可以定期透過公開的端點存取。 此模式可協助您驗證應用程式和服務是否正常執行。