這篇文章我們繼續(xù)聊分布式相關的內(nèi)容。

提到分布式系統(tǒng)，就一定繞不開“一致性”，這次我們說說：最終一致性。

最終一致性是現(xiàn)在大部分高可用的分布式系統(tǒng)的核心思路。

估計有人對最終一致性不太熟，先來個簡單介紹：

最終一致性指的是系統(tǒng)中的所有分散在不同節(jié)點的數(shù)據(jù)，經(jīng)過一定時間后，最終能夠達到符合業(yè)務定義的一致的狀態(tài)。

劃重點：

1. 是數(shù)據(jù)一致性，不是事務一致性（ACID 是事務一致性）；
2. 存在條件：多個節(jié)點/系統(tǒng)；
3. 不一致可能是暫時的，最終要一致（鬼知道“最終”是多久）

好，正文開始。

莫看江面平如鏡，要看水底萬丈深

最終一致性，一言以蔽之，過程松，結(jié)果緊。不管中間過程如何，結(jié)果必須符合業(yè)務需求，滿足數(shù)據(jù)一致性的要求。

雖然，在實現(xiàn)中，有各種花樣百出的方案，但是本質(zhì)的思想都是一樣的。我們現(xiàn)在就來忽略那些亂花迷眼的過程，仔細探討下最終一致性的本質(zhì)。

何事居窮道不窮，亂時還與凈時同

在我剛?cè)胄胁痪玫臅r候，能力有限，菜鳥一個，只能做一些小的功能模塊。我印象最深的就是訂單模塊。

用戶下單，訂單模塊收到下單請求后，執(zhí)行對應的訂單業(yè)務邏輯。最終，會把訂單插入到訂單表，并返回下單結(jié)果給用戶。用戶結(jié)算后，訂單模塊就會去根據(jù)支付情況去更新訂單狀態(tài)。

就這點事兒，對我這個技術渣渣來說，開始也著實費了一番手腳，不過最終也成了熟手，維護起這個模塊來也駕輕就熟了。

這種簡單的小日子過了一陣子后，新任務來了！

產(chǎn)品經(jīng)理告訴我，數(shù)據(jù)審計部門想要我維護的這個訂單模塊在訂單完成后，能及時分發(fā)一份訂單數(shù)據(jù)給他們。他們提供了一個接口，讓我直接傳數(shù)據(jù)給他們。

兩個問題出現(xiàn)了：

問題 1：用戶等待時間變長

最簡單的實現(xiàn)就是我更新完訂單數(shù)據(jù)后，再順序去調(diào)用數(shù)據(jù)審計部門給的接口，把訂單數(shù)據(jù)傳過去。

但是，從用戶結(jié)算成功到更新訂單狀態(tài)這一系列的流程是同步的，假設這一系列流程所花費的時間是 n 毫秒。這就意味著，用戶需要等待至少 n 毫秒。如果再加上傳給數(shù)據(jù)審計部門的操作時間，假設為 m 毫秒，則整個用戶就需要等待就 n+m 毫秒。

整個功能用戶等待時間成本上升，體驗下降。如下圖：

問題 2：部分成功，部分失敗

引入新的接口后，某些時候調(diào)用這個接口可能會失敗，比如網(wǎng)絡問題啊，驗證問題啊，接口服務失敗啊，很多原因。那么問題來了，新接口失敗的時候怎么處理？

如果訂單更新成功，傳給數(shù)據(jù)審計部門的時候失敗了，這種情況會讓訂單模塊的后續(xù)處理變得很尷尬。

首先你不可能返回給客戶端說你這次結(jié)算失敗了，請求就沒失敗，你憑什么說人家失敗了？其次，你又不能說這次業(yè)務上就是成功的，因為數(shù)據(jù)審計其實還挺重要的，它是業(yè)務邏輯的重要組成部分。

真是進退兩難。

這兩個問題的解決方案其中之一就是最終一致性。

我們以前談到過 CAP，知道如果犧牲一定的一致性就可以保證分區(qū)容錯性和可用性。而最終一致性則是不能保證同時讓所有的數(shù)據(jù)當時都符合業(yè)務需求，但是我們能保證任何時候服務在內(nèi)部出現(xiàn)問題的時候都是可對外服務的。

四哥我平時喜歡玩游戲，那我們就用一個淘寶買 Switch 的例子，來解釋最終一致性：

如果你想在淘寶同時買一個 Switch 的數(shù)字版游戲和一臺 Switch，那么你付完錢后，你就可以立刻得到數(shù)字版的游戲，但是，對于那臺購買的 Switch，你就要等幾天，等到快遞投遞到家才可以拿到。

來梳理下這個例子的細節(jié)：

• 首先淘寶上肯定得有個對顧客售賣 Switch 和數(shù)字游戲的商家去接受我們下的訂單，并給你一個單號。
• 你得到了一個數(shù)字版游戲，但是沒拿到 Switch。
• 你不知道這個商家背后 Switch 是怎么給你準備的，是不是中間他沒貨了還得跑別的商家串貨，又或者沒貨等了兩天才發(fā)給你(延遲發(fā)貨可以給出別的理由，不再贅述)。這些不重要，重要的是你明確對方接單了他就要完成這筆單子。
• 你下單成功之后，你就有了保障，你最終會拿到你的 Switch，只是你可能不太肯定什么時候收到。

過了幾天，你終于收到貨了，恩，恭喜你成功入坑 Switch。

上面的例子就是我們說的最終一致性。但是，這里有個非常非常重要的東西還沒有凸顯出來，即到底是什么樣的原因在驅(qū)使我們使用最終一致性？

答案就是數(shù)據(jù)的分發(fā)。

紙上得來終覺淺，絕知此事要躬行

為什么我們會出現(xiàn)需要最終一致性的情況呢？

因為我們需要把數(shù)據(jù)分發(fā)到不同的地方上去，而由于分發(fā)數(shù)據(jù)到不同的地方，就會導致，可能中間分發(fā)過程中出現(xiàn)分發(fā)成功或者失敗的不一致情況，就需要最終一致性這種思路來處理這些情況。

恩，分發(fā)數(shù)據(jù)……OK，你想到了吧？

沒錯，通過 MQ 分發(fā)消息就可以處理分發(fā)數(shù)據(jù)的情況，而這正是最終一致性最常用的實現(xiàn)手段。

我們把要分發(fā)的數(shù)據(jù)打包成消息，再發(fā)送給 MQ 中間件。中間件會廣播這些數(shù)據(jù)給所有想要收到這些消息的服務。這些收到消息的服務就根據(jù)自己的業(yè)務情況對數(shù)據(jù)進行獨立的處理。

回到我們訂單模塊的那個例子，我們可以采用兩種方式使用最終一致性。

1. 先插入數(shù)據(jù)庫，后發(fā)消息給數(shù)據(jù)審計

這個方式，訂單模塊先更新訂單狀態(tài)。然后，把訂單數(shù)據(jù)打包成消息發(fā)送到 MQ 中，訂單模塊的任務就結(jié)束了。剩下的任務就是由數(shù)據(jù)審計部門根據(jù)自己的業(yè)務，從 MQ 中獲取消息后進行對應的處理。

這個方法里，我們既保證數(shù)據(jù)庫更新成功也保證數(shù)據(jù)被發(fā)送到了 MQ 中。最終，當數(shù)據(jù)審計部門收到消息并根據(jù)消息內(nèi)容做完對應的處理后，則整體數(shù)據(jù)達到最終一致的狀態(tài)。

1. 只插入到 MQ 中

這個方式，訂單模塊直接收到請求后，將數(shù)據(jù)打包成消息放入到 MQ 中。

然后，再由訂單模塊自己和數(shù)據(jù)審計部門的服務分別從 MQ 中拿到對應的消息，再各自根據(jù)自己的業(yè)務邏輯該更新數(shù)據(jù)庫的更新數(shù)據(jù)庫，該走自己的審計的走自己的審計，最終達到一致的狀態(tài)。

小荷才露尖尖角,早有蜻蜓立上頭

在以上的例子中，我們描述了最終一致性的核心思路，不保證數(shù)據(jù)狀態(tài)能實時滿足業(yè)務要求，但是就像我們在線購物一樣，我們能保證在間隔了一段時間窗口后肯定能滿足業(yè)務需求。

然而，雖然說起來簡單，但是世間上的事情又哪里那么容易呢？根據(jù)業(yè)務的不同，最終一致性分化出了多種實現(xiàn)思路。比如，

重試 + 逆向模式

在我們做支付時，需要記賬，當記賬不成功時，我們可能希望能盡可能的重試。當重試達到某種限制后，甚至我們還要通知上游系統(tǒng)去提供一個重試和取消接口，讓下游能通知上游重發(fā)消息，或者先暫時取消操作。

補救任務模式

在我們做支付記賬失敗了，我們又嘗試了重試 + 逆向模式取消了操作，那么此時就可以創(chuàng)建一個補救任務，等到后期可以保證記賬成功的時候去執(zhí)行這個任務。

異步消息模式

在我們做轉(zhuǎn)賬的時候，我們肯定是要保證 A 轉(zhuǎn)出后 B 轉(zhuǎn)入這種業(yè)務是強一致性的。然而，可能此時又需要跨服務。同時，我們還想盡量保證性能。那么，這個時候我們就可以先把本地對數(shù)據(jù)庫的寫操作和要跨服務的消息做成事務，然后，后期再根據(jù)消息被處理的狀態(tài)做整體事務的提交和回滾。

可以看到，最終一致性的實現(xiàn)方式是多種多樣的，但是，它始終逃不過一個核心，通過消息隊列分發(fā)數(shù)據(jù)。在明白了這個根本原則后，以后我們理解各種各樣的分布式事務，分布式共識等就會容易許多了。