這篇文章咱們繼續聊分佈式相關的內容。數據庫
提到分佈式系統，就必定繞不開「一致性」，此次咱們說說：最終一致性。網絡
最終一致性是如今大部分高可用的分佈式系統的核心思路。異步
估計有人對最終一致性不太熟，先來個簡單介紹：分佈式
最終一致性指的是系統中的全部分散在不一樣節點的數據，通過必定時間後，最終可以達到符合業務定義的一致的狀態。性能
劃重點：spa
- 是數據一致性，不是事務一致性（ACID 是事務一致性）；
- 存在條件：多個節點/系統；
- 不一致多是暫時的，最終要一致（鬼知道「最終」是多久）
好，正文開始。中間件
莫看江面平如鏡，要看水底萬丈深
最終一致性，一言以蔽之，過程鬆，結果緊。無論中間過程如何，結果必須符合業務需求，知足數據一致性的要求。blog
雖然，在實現中，有各類花樣百出的方案，可是本質的思想都是同樣的。咱們如今就來忽略那些亂花迷眼的過程，仔細探討下最終一致性的本質。接口
何事居窮道不窮，亂時還與淨時同
在我剛入行不久的時候，能力有限，菜鳥一個，只能作一些小的功能模塊。我印象最深的就是訂單模塊。隊列
用戶下單，訂單模塊收到下單請求後，執行對應的訂單業務邏輯。最終，會把訂單插入到訂單表，並返回下單結果給用戶。用戶結算後，訂單模塊就會去根據支付狀況去更新訂單狀態。
就這點事兒，對我這個技術渣渣來講，開始也着實費了一番手腳，不過最終也成了熟手，維護起這個模塊來也得心應手了。
這種簡單的小日子過了一陣子後，新任務來了！
產品經理告訴我，數據審計部門想要我維護的這個訂單模塊在訂單完成後，能及時分發一份訂單數據給他們。他們提供了一個接口，讓我直接傳數據給他們。
兩個問題出現了：
問題 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 轉入這種業務是強一致性的。然而，可能此時又須要跨服務。同時，咱們還想盡可能保證性能。那麼，這個時候咱們就能夠先把本地對數據庫的寫操做和要跨服務的消息作成事務，而後，後期再根據消息被處理的狀態作總體事務的提交和回滾。
能夠看到，最終一致性的實現方式是多種多樣的，可是，它始終逃不過一個核心，經過消息隊列分發數據。在明白了這個根本原則後，之後咱們理解各類各樣的分佈式事務，分佈式共識等就會容易許多了。
完