石頭自清潔掃拖機器人G10S評測：多年黑科技集大成之作 懶人終極福音
科技圈經常能看到一個詞叫“縫合怪”，用來形容那些把好多功能或者外觀結合在一起的產品，通常這樣的詞是貶義詞，但如果真的是產品縫合的好、縫合的實用的話，那它就成了中性詞，今
最強大的事務類型之一稱為兩階段提交，當第一個事務的提交取決于第二個事務的完成時，它是摘要。特別是當您必須同時更新多個實體時，例如確認訂單和立即更新庫存時，它非常有用。
但是，例如，當您使用微服務時，事情變得更加復雜。每個服務都是一個獨立的系統，擁有自己的數據庫，您不再可以利用本地兩階段提交的簡單性來維護整個系統的一致性。
當你失去這種能力時，RDBMS成為一個非常糟糕的存儲選擇，因為你可以完成相同的“單實體原子事務”，但只需使用像Couchbase這樣的NoSQL數據庫就可以快幾十倍。這就是為什么大多數使用微服務的公司也在使用NoSQL。
要舉例說明此問題，請考慮以下電子商務系統的高級微服務架構：
圖片
在上面的示例中，人們不能只在一個ACID交易中下訂單，向客戶收費，更新庫存，并將其發送到交貨。要始終如一地執行此整個流程，您將需要創建分布式事務。
我們都知道實現分布式任務是多么困難，不幸的是，交易也不例外。處理瞬態狀態，服務，隔離和回滾之間的最終一致性是在設計階段應該考慮的場景。
幸運的是，我們已經為它提出了一些好的模式，因為我們已經實施分布式事務已有二十多年了。我今天要談的那個叫做Saga模式。
分布式事務最著名的模式之一稱為Saga。關于它的第一篇論文發表于1987年，從那時起它就成了一種流行的解決方案。
Saga是一系列本地事務，其中每個事務在單個服務中更新數據。第一個事務由對應于系統操作的外部請求啟動，然后每個后續步驟由前一個完成觸發。
使用我們之前的電子商務示例，在一個非常高級的設計中，Saga實現如下所示：
圖片
有幾種不同的方法來實現傳奇交易，但最受歡迎的兩種方式是：
讓我們更深入地了解每個實現，以了解它們的工作原理。
在事件/Choreography(編舞)方法中，第一個服務執行事務然后發布事件。該事件由一個或多個服務監聽，這些服務執行本地事務并發布（或不發布）新事件。
當最后一個服務執行其本地事務并且不發布任何事件時，分布式事務結束，或者任何傳奇(Saga)參與者都不會聽到發布的事件。
讓我們看看它在我們的電子商務示例中的樣子：
圖片
在上面的情況中，如果需要跟蹤訂單的狀態，訂單服務可以簡單地監聽所有事件并更新其狀態。
回滾分布式事務并非免費。通常，您必須實施另一個操作/事務來補償之前已完成的操作。
假設Stock Service在交易期間失敗了。讓我們看看回滾會是什么樣子：
圖片
請注意，為每個事務定義一個公共共享ID至關重要，因此每當您拋出一個事件時，所有偵聽器都可以立即知道它所引用的事務。
事件/編排是實現Saga模式的自然方式;它簡單，易于理解，不需要太多的努力來構建，并且所有參與者都是松散耦合的，因為他們沒有彼此的直接知識。如果您的交易涉及2到4個步驟，那么它可能非常合適。
但是，如果您不斷在事務中添加額外的步驟，這種方法很快就會變得混亂，因為很難跟蹤哪些服務監聽哪些事件。此外，它還可能在服務之間添加循環依賴，因為它們必須訂閱彼此的事件。
最后，使用這種設計實現測試會很棘手。為了模擬事務行為，您應該運行所有服務。
本文鏈接：http://www.www897cc.com/showinfo-26-55173-0.htmlSaga 模式 | 如何使用微服務實現業務事務
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號