建站
咨詢
售后
建站咨詢
新聞中心
最強大的事務類型之一稱為兩階段提交，當?shù)谝粋€事務的提交取決于第二個事務的完成時，它是摘要。特別是當您必須同時更新多個實體時，例如確認訂單和立即更新庫存時，它非常有用。
創(chuàng)新互聯(lián)建站一直通過網(wǎng)站建設和網(wǎng)站營銷幫助企業(yè)獲得更多客戶資源。 以"深度挖掘，量身打造，注重實效"的一站式服務，以網(wǎng)站建設、成都網(wǎng)站制作、移動互聯(lián)產(chǎn)品、全網(wǎng)整合營銷推廣服務為核心業(yè)務。10余年網(wǎng)站制作的經(jīng)驗，使用新網(wǎng)站建設技術(shù)，全新開發(fā)出的標準網(wǎng)站，不但價格便宜而且實用、靈活，特別適合中小公司網(wǎng)站制作。網(wǎng)站管理系統(tǒng)簡單易用，維護方便，您可以完全操作網(wǎng)站資料，是中小公司快速網(wǎng)站建設的選擇。
但是，例如，當您使用微服務時，事情變得更加復雜。每個服務都是一個獨立的系統(tǒng)，擁有自己的數(shù)據(jù)庫，您不再可以利用本地兩階段提交的簡單性來維護整個系統(tǒng)的一致性。
當你失去這種能力時，RDBMS成為一個非常糟糕的存儲選擇，因為你可以完成相同的“單實體原子事務”，但只需使用像Couchbase這樣的NoSQL數(shù)據(jù)庫就可以快幾十倍。這就是為什么大多數(shù)使用微服務的公司也在使用NoSQL。
要舉例說明此問題，請考慮以下電子商務系統(tǒng)的高級微服務架構(gòu)：
圖片
在上面的示例中，人們不能只在一個ACID交易中下訂單，向客戶收費，更新庫存，并將其發(fā)送到交貨。要始終如一地執(zhí)行此整個流程，您將需要創(chuàng)建分布式事務。
我們都知道實現(xiàn)分布式任務是多么困難，不幸的是，交易也不例外。處理瞬態(tài)狀態(tài)，服務，隔離和回滾之間的最終一致性是在設計階段應該考慮的場景。
幸運的是，我們已經(jīng)為它提出了一些好的模式，因為我們已經(jīng)實施分布式事務已有二十多年了。我今天要談的那個叫做Saga模式。
傳奇(Saga)模式
分布式事務最著名的模式之一稱為Saga。關(guān)于它的第一篇論文發(fā)表于1987年，從那時起它就成了一種流行的解決方案。
Saga是一系列本地事務，其中每個事務在單個服務中更新數(shù)據(jù)。第一個事務由對應于系統(tǒng)操作的外部請求啟動，然后每個后續(xù)步驟由前一個完成觸發(fā)。
使用我們之前的電子商務示例，在一個非常高級的設計中，Saga實現(xiàn)如下所示：
圖片
有幾種不同的方法來實現(xiàn)傳奇交易，但最受歡迎的兩種方式是：
- 事件/Choreography(編舞)：當沒有中央?yún)f(xié)調(diào)時，每個服務產(chǎn)生并監(jiān)聽其他服務的事件，并決定是否應該采取行動。
- 命令 / Orchestration(編曲)：協(xié)調(diào)器服務負責集中saga的決策和排序業(yè)務邏輯。
讓我們更深入地了解每個實現(xiàn)，以了解它們的工作原理。
事件/編舞
在事件/Choreography(編舞)方法中，第一個服務執(zhí)行事務然后發(fā)布事件。該事件由一個或多個服務監(jiān)聽，這些服務執(zhí)行本地事務并發(fā)布（或不發(fā)布）新事件。
當最后一個服務執(zhí)行其本地事務并且不發(fā)布任何事件時，分布式事務結(jié)束，或者任何傳奇(Saga)參與者都不會聽到發(fā)布的事件。
讓我們看看它在我們的電子商務示例中的樣子：
圖片
- 訂單服務保存新訂單，將狀態(tài)設置為掛起并發(fā)布名為ORDER_CREATED_EVENT的事件。
- 付款服務偵聽ORDER_CREATED_EVENT，向客戶收費并發(fā)布事件BILLED_ORDER_EVENT。
- Stock Service監(jiān)聽BILLED_ORDER_EVENT，更新庫存，準備訂單中購買的產(chǎn)品并發(fā)布ORDER_PREPARED_EVENT。
- Delivery Service偵聽ORDER_PREPARED_EVENT，然后選擇并交付產(chǎn)品。最后，它發(fā)布了ORDER_DELIVERED_EVENT
- 最后，Order Service偵聽ORDER_DELIVERED_EVENT并將訂單狀態(tài)設置為已結(jié)束。
在上面的情況中，如果需要跟蹤訂單的狀態(tài)，訂單服務可以簡單地監(jiān)聽所有事件并更新其狀態(tài)。
分布式事務中的回滾
回滾分布式事務并非免費。通常，您必須實施另一個操作/事務來補償之前已完成的操作。
假設Stock Service在交易期間失敗了。讓我們看看回滾會是什么樣子：
圖片
- 庫存服務生產(chǎn)PRODUCT_OUT_OF_STOCK_EVENT;
- 訂單服務和付款服務都會收聽上一條消息：
- 付款服務退還客戶。
- 訂單服務將訂單狀態(tài)設置為失敗。
請注意，為每個事務定義一個公共共享ID至關(guān)重要，因此每當您拋出一個事件時，所有偵聽器都可以立即知道它所引用的事務。
Saga 事件/Choreography(編舞)設計的好處和缺點
事件/編排是實現(xiàn)Saga模式的自然方式;它簡單，易于理解，不需要太多的努力來構(gòu)建，并且所有參與者都是松散耦合的，因為他們沒有彼此的直接知識。如果您的交易涉及2到4個步驟，那么它可能非常合適。
但是，如果您不斷在事務中添加額外的步驟，這種方法很快就會變得混亂，因為很難跟蹤哪些服務監(jiān)聽哪些事件。此外，它還可能在服務之間添加循環(huán)依賴，因為它們必須訂閱彼此的事件。
最后，使用這種設計實現(xiàn)測試會很棘手。為了模擬事務行為，您應該運行所有服務。
網(wǎng)頁標題：Saga模式|如何使用微服務實現(xiàn)業(yè)務事務
轉(zhuǎn)載來源：http://www.5511xx.com/article/dpsegjh.html
