最強(qiáng)大的事務(wù)類型之一稱為兩階段提交，當(dāng)?shù)谝粋€(gè)事務(wù)的提交取決于第二個(gè)事務(wù)的完成時(shí)，它是摘要。特別是當(dāng)您必須同時(shí)更新多個(gè)實(shí)體時(shí)，例如確認(rèn)訂單和立即更新庫存時(shí)，它非常有用。

但是，例如，當(dāng)您使用微服務(wù)時(shí)，事情變得更加復(fù)雜。每個(gè)服務(wù)都是一個(gè)獨(dú)立的系統(tǒng)，擁有自己的數(shù)據(jù)庫，您不再可以利用本地兩階段提交的簡單性來維護(hù)整個(gè)系統(tǒng)的一致性。

當(dāng)你失去這種能力時(shí)，RDBMS成為一個(gè)非常糟糕的存儲(chǔ)選擇，因?yàn)槟憧梢酝瓿上嗤摹皢螌?shí)體原子事務(wù)”，但只需使用像Couchbase這樣的NoSQL數(shù)據(jù)庫就可以快幾十倍。這就是為什么大多數(shù)使用微服務(wù)的公司也在使用NoSQL。

要舉例說明此問題，請(qǐng)考慮以下電子商務(wù)系統(tǒng)的高級(jí)微服務(wù)架構(gòu)：

圖片

在上面的示例中，人們不能只在一個(gè)ACID交易中下訂單，向客戶收費(fèi)，更新庫存，并將其發(fā)送到交貨。要始終如一地執(zhí)行此整個(gè)流程，您將需要?jiǎng)?chuàng)建分布式事務(wù)。

我們都知道實(shí)現(xiàn)分布式任務(wù)是多么困難，不幸的是，交易也不例外。處理瞬態(tài)狀態(tài)，服務(wù)，隔離和回滾之間的最終一致性是在設(shè)計(jì)階段應(yīng)該考慮的場景。

幸運(yùn)的是，我們已經(jīng)為它提出了一些好的模式，因?yàn)槲覀円呀?jīng)實(shí)施分布式事務(wù)已有二十多年了。我今天要談的那個(gè)叫做Saga模式。

傳奇(Saga)模式

分布式事務(wù)最著名的模式之一稱為Saga。關(guān)于它的第一篇論文發(fā)表于1987年，從那時(shí)起它就成了一種流行的解決方案。

Saga是一系列本地事務(wù)，其中每個(gè)事務(wù)在單個(gè)服務(wù)中更新數(shù)據(jù)。第一個(gè)事務(wù)由對(duì)應(yīng)于系統(tǒng)操作的外部請(qǐng)求啟動(dòng)，然后每個(gè)后續(xù)步驟由前一個(gè)完成觸發(fā)。

使用我們之前的電子商務(wù)示例，在一個(gè)非常高級(jí)的設(shè)計(jì)中，Saga實(shí)現(xiàn)如下所示：

圖片

有幾種不同的方法來實(shí)現(xiàn)傳奇交易，但最受歡迎的兩種方式是：

1. 事件/Choreography(編舞)：當(dāng)沒有中央?yún)f(xié)調(diào)時(shí)，每個(gè)服務(wù)產(chǎn)生并監(jiān)聽其他服務(wù)的事件，并決定是否應(yīng)該采取行動(dòng)。
2. 命令 / Orchestration(編曲)：協(xié)調(diào)器服務(wù)負(fù)責(zé)集中saga的決策和排序業(yè)務(wù)邏輯。

讓我們更深入地了解每個(gè)實(shí)現(xiàn)，以了解它們的工作原理。

事件/編舞

在事件/Choreography(編舞)方法中，第一個(gè)服務(wù)執(zhí)行事務(wù)然后發(fā)布事件。該事件由一個(gè)或多個(gè)服務(wù)監(jiān)聽，這些服務(wù)執(zhí)行本地事務(wù)并發(fā)布（或不發(fā)布）新事件。

當(dāng)最后一個(gè)服務(wù)執(zhí)行其本地事務(wù)并且不發(fā)布任何事件時(shí)，分布式事務(wù)結(jié)束，或者任何傳奇(Saga)參與者都不會(huì)聽到發(fā)布的事件。

讓我們看看它在我們的電子商務(wù)示例中的樣子：

圖片

1. 訂單服務(wù)保存新訂單，將狀態(tài)設(shè)置為掛起并發(fā)布名為ORDER_CREATED_EVENT的事件。
2. 付款服務(wù)偵聽ORDER_CREATED_EVENT，向客戶收費(fèi)并發(fā)布事件BILLED_ORDER_EVENT。
3. Stock Service監(jiān)聽BILLED_ORDER_EVENT，更新庫存，準(zhǔn)備訂單中購買的產(chǎn)品并發(fā)布ORDER_PREPARED_EVENT。
4. Delivery Service偵聽ORDER_PREPARED_EVENT，然后選擇并交付產(chǎn)品。最后，它發(fā)布了ORDER_DELIVERED_EVENT
5. 最后，Order Service偵聽ORDER_DELIVERED_EVENT并將訂單狀態(tài)設(shè)置為已結(jié)束。

在上面的情況中，如果需要跟蹤訂單的狀態(tài)，訂單服務(wù)可以簡單地監(jiān)聽所有事件并更新其狀態(tài)。

分布式事務(wù)中的回滾

回滾分布式事務(wù)并非免費(fèi)。通常，您必須實(shí)施另一個(gè)操作/事務(wù)來補(bǔ)償之前已完成的操作。

假設(shè)Stock Service在交易期間失敗了。讓我們看看回滾會(huì)是什么樣子：

圖片

1. 庫存服務(wù)生產(chǎn)PRODUCT_OUT_OF_STOCK_EVENT;
2. 訂單服務(wù)和付款服務(wù)都會(huì)收聽上一條消息：

• 付款服務(wù)退還客戶。
• 訂單服務(wù)將訂單狀態(tài)設(shè)置為失敗。

請(qǐng)注意，為每個(gè)事務(wù)定義一個(gè)公共共享ID至關(guān)重要，因此每當(dāng)您拋出一個(gè)事件時(shí)，所有偵聽器都可以立即知道它所引用的事務(wù)。

Saga 事件/Choreography(編舞)設(shè)計(jì)的好處和缺點(diǎn)

事件/編排是實(shí)現(xiàn)Saga模式的自然方式;它簡單，易于理解，不需要太多的努力來構(gòu)建，并且所有參與者都是松散耦合的，因?yàn)樗麄儧]有彼此的直接知識(shí)。如果您的交易涉及2到4個(gè)步驟，那么它可能非常合適。

但是，如果您不斷在事務(wù)中添加額外的步驟，這種方法很快就會(huì)變得混亂，因?yàn)楹茈y跟蹤哪些服務(wù)監(jiān)聽哪些事件。此外，它還可能在服務(wù)之間添加循環(huán)依賴，因?yàn)樗鼈儽仨氂嗛啽舜说氖录?/p>

最后，使用這種設(shè)計(jì)實(shí)現(xiàn)測試會(huì)很棘手。為了模擬事務(wù)行為，您應(yīng)該運(yùn)行所有服務(wù)。