這篇文章我們聊分布式相關的內容。

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

最終一致性是現在大部分高可用的分布式系統的核心思路。

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

最終一致性指的是系統中的所有分散在不同節點的數據，經過一定時間后，最終能夠達到符合業務定義的一致的狀態。

劃重點：

是數據一致性，不是事務一致性（ACID 是事務一致性）；

存在條件：多個節點/系統；

不一致可能是暫時的，最終要一致（鬼知道“最終”是多久）

好，正文開始。

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

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

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

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

在我剛入行不久的時候，能力有限，菜鳥一個，只能做一些小的功能模塊。我印象最深的就是訂單模塊。

用戶下單，訂單模塊收到下單請求后，執行對應的訂單業務邏輯。最終，會把訂單插入到訂單表，并返回下單結果給用戶。用戶結算后，訂單模塊就會去根據支付情況去更新訂單狀態。

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

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

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

兩個問題出現了：

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

最簡單的實現就是我更新完訂單數據后，再順序去調用數據審計部門給的接口，把訂單數據傳過去。

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

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

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

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

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

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

真是進退兩難。

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

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

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

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

來梳理下這個例子的細節：

首先淘寶上肯定得有個對顧客售賣 Switch 和數字游戲的商家去接受我們下的訂單，并給你一個單號。

你得到了一個數字版游戲，但是沒拿到 Switch。

你不知道這個商家背后 Switch 是怎么給你準備的，是不是中間他沒貨了還得跑別的商家串貨，又或者沒貨等了兩天才發給你(延遲發貨可以給出別的理由，不再贅述)。這些不重要，重要的是你明確對方接單了他就要完成這筆單子。

你下單成功之后，你就有了保障，你最終會拿到你的 Switch，只是你可能不太肯定什么時候收到。

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

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

答案就是數據的分發。

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

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

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

恩，分發數據……OK，你想到了吧？

沒錯，通過 MQ 分發消息就可以處理分發數據的情況，而這正是最終一致性最常用的實現手段。

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

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

先插入數據庫，后發消息給數據審計

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

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

只插入到 MQ 中

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

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

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

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

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

重試 + 逆向模式

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

補救任務模式

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

異步消息模式

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

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

原文標題：最終一致性，一致只會遲到，但絕不會缺席

文章出處：【微信公眾號：Linux愛好者】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq