這篇文章我們繼續聊分散式相關的內容。
提到分散式系統，就一定繞不開“一致性”，這次我們說說：最終一致性。
最終一致性是現在大部分高可用的分散式系統的核心思路。
估計有人對最終一致性不太熟，先來個簡單介紹：
最終一致性指的是系統中的所有分散在不同節點的資料，經過一定時間後，最終能夠達到符合業務定義的一致的狀態。
劃重點：
- 是資料一致性，不是事務一致性（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 轉入這種業務是強一致性的。然而，可能此時又需要跨服務。同時，我們還想盡量保證效能。那麼，這個時候我們就可以先把本地對資料庫的寫操作和要跨服務的訊息做成事務，然後，後期再根據訊息被處理的狀態做整體事務的提交和回滾。
可以看到，最終一致性的實現方式是多種多樣的，但是，它始終逃不過一個核心，通過訊息佇列分發資料。在明白了這個根本原則後，以後我們理解各種各樣的分散式事務，分散式共識等就會容易許多了。
完