這篇文章我們聊分布式相關(guān)的內(nèi)容。

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

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

估計(jì)有人對(duì)最終一致性不太熟，先來個(gè)簡單介紹：

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

劃重點(diǎn)：

是數(shù)據(jù)一致性，不是事務(wù)一致性（ACID 是事務(wù)一致性）；

存在條件：多個(gè)節(jié)點(diǎn)/系統(tǒng)；

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

好，正文開始。

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

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

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

何事居窮道不窮，亂時(shí)還與凈時(shí)同

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

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

就這點(diǎn)事兒，對(duì)我這個(gè)技術(shù)渣渣來說，開始也著實(shí)費(fèi)了一番手腳，不過最終也成了熟手，維護(hù)起這個(gè)模塊來也駕輕就熟了。

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

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

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

問題 1：用戶等待時(shí)間變長

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

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

整個(gè)功能用戶等待時(shí)間成本上升，體驗(yàn)下降。

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

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

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

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

真是進(jìn)退兩難。

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

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

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

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

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

首先淘寶上肯定得有個(gè)對(duì)顧客售賣 Switch 和數(shù)字游戲的商家去接受我們下的訂單，并給你一個(gè)單號(hào)。

你得到了一個(gè)數(shù)字版游戲，但是沒拿到 Switch。

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

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

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

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

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

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

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

因?yàn)槲覀冃枰褦?shù)據(jù)分發(fā)到不同的地方上去，而由于分發(fā)數(shù)據(jù)到不同的地方，就會(huì)導(dǎo)致，可能中間分發(fā)過程中出現(xiàn)分發(fā)成功或者失敗的不一致情況，就需要最終一致性這種思路來處理這些情況。

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

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

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

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

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

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

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

只插入到 MQ 中

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

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

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

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

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

重試 + 逆向模式

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

補(bǔ)救任務(wù)模式

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

異步消息模式

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

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

原文標(biāo)題：最終一致性，一致只會(huì)遲到，但絕不會(huì)缺席

文章出處：【微信公眾號(hào)：Linux愛好者】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責(zé)任編輯：haq