分散式系統(微服務架構)的一致性和冪等性問題相關概念解析

目錄

• 前言
• 1. 分散式系統的資料一致性
  • 1.1 分散式儲存系統中的一致性問題
  • 1.2 微服務應用的分散式一致性問題
  • 1.3 對於一致性的正確理解
• 2.分散式一致性模型
• 3. 追求強一致性的約束——CAP定理
  • 3.1 如何理解CAP三要素不可兼得
  • 3.2 如何正確理解CAP定理
• 4. 一致性的妥協——最終一致性和Base原則
  • 4.1 CAP,BASE以及ACID的關係
• 5. 分散式系統的冪等性
• 6.微服務架構的分散式一致性和冪等性問題
  • 6.1 微服務架構下的分散式一致性問題
  • 6.2 微服務架構下的冪等性問題
• 7. 參考資料

前言

什麼是分散式系統?關於這點其實並沒有明確且統一的定義。在我看來,只要一個系統滿足以下幾點就可以稱之為分散式系統

• 系統由物理上不同分佈的多個機器節點組成
• 系統的多個節點通過網路進行通訊,協調彼此之間的工作。
• 系統作為整體統一對外提供服務,其分散式細節對客戶端透明。

要想更好的理解分散式系統,並正確使用甚至構建分散式系統,需要理解其中的兩個關鍵概念——分散式系統的資料一致性和分散式系統的冪等性。

1. 分散式系統的資料一致性

對於分散式系統,資料可能存在於不同的物理節點上,節點之間只能通過網路進行通訊來協調彼此之間的狀態,而網路通訊需要時間並且其本身並不十分可靠,因而如何保持資料一致性成為了分散式系統的難題。對於不同的分散式系統,其一致性語義以及面對的一致性難題可能略有差別

1.1 分散式儲存系統中的一致性問題

在分散式儲存系統中,為了保持系統的高可用,同時增加讀操作的併發性,同一份資料會有多份副本,不同的副本儲存於不同的節點上,如下圖所示

在併發環境下,因為存在多個客戶端同時讀取同一資料在不同節點上的副本,因而如何維護資料的一致性檢視就非常重要,即對於使用該分散式系統的客戶端而言,對於多副本資料的讀寫其表現應該和單份資料一樣,通常系統是通過資料複製的方式來達到這一點的,

• 客戶端將節點1中的副本A修改為10,系統將通過網路通訊的方式將節點2和節點3中的副本A也更新為10。然而網路通訊是需要時間的,假設在系統還未將節點1中的A值同步到節點2和節點3,此時另一個客戶端訪問了節點2和節點3,這個時候系統怎麼辦？
• 甚至,考慮更極端的場景,節點之間的網路被斷開,不同節點無法感知到彼此的存在,當然也就無法保持多副本資料的同一檢視,那麼這個時候系統又該怎麼辦？

1.2 微服務應用的分散式一致性問題

微服務架構下,原有的單體應用按功能被拆分成一個個微服務應用,每個微服務應用被部署在不同的機器節點上,只完成原有單體應用的某一部分功能,操作屬於該業務功能的資料庫或表。彼此之前通過網路通訊的方式協調彼此之間的工作,作為整體共同對外提供服務,因而一個業務功能的實現,可能會涉及到多個微服務的呼叫,操作物理上不同的多個數據庫或表。比如對於下單並支付這個業務功能而言,需要呼叫下單微服務和支付微服務來共同完成。

對於下單並支付這一業務功能,應用先呼叫訂單微服務,在訂單資料庫中新增一條訂單記錄,成功後再呼叫支付微服務新增相應的支付記錄,只有這兩個微服務都呼叫成功,該業務功能才算執行成功。這個過程可能存在以下的問題:

• 訂單微服務呼叫成功,訂單記錄已落地,但是支付微服務由於各種原因遲遲得不到響應,此時使用者通過訂單號查詢只能查到訂單記錄而查不到支付記錄,這對於已經成功付款的使用者而言肯定是無法接受的,這種情況該怎麼辦？

• 訂單微服務呼叫成功,訂單記錄已落地,但是支付微服務呼叫失敗,此時訂單記錄和支付記錄所對應的業務狀態不一致,這時候系統該怎麼辦?

1.3 對於一致性的正確理解

分散式儲存系統的一致性問題,主要在於如何維持多副本的一致性檢視上,即如何使多份資料對外表現的和一份資料一樣。而微服務架構下的分散式應用系統,其一致性問題主要在於如何使不同微服務的資料對同一業務狀態的描述保持一致,比如對於下單並支付這一業務操作而言,下單和支付要麼同時成功,要麼應該同時失敗,而不應該一個成功一個失敗,並且在這個過程中,某部分已經成功或失敗的資料是否應該對客戶端可見。在聯絡一下本地事務ACID中的一致性,我們可能會產生一定的混亂:它們講的一致性是一個東西嗎？先說下我的個人理解:不管是ACID的一致性還是不同分散式系統中的一致性,它們本質上講的是一件事:資料的一致性,在於正確的反應現實世界,對發生於現實世界的事情的正確描述。這就要求,一致性的資料至少要滿足以下兩個條件:

• 1.符合系統本身具有的約束條件,比如資料庫中的資料要遵循主碼,外碼,check約束。
• 2.與特定業務有關的所有資料,它們對業務執行狀態的描述應該保持一致。比如從A賬戶轉賬100元到B賬戶這一業務操作,不管A賬戶和B賬戶是否在一個數據庫,也不管這一業務操作是否執行成功,兩個賬戶的總金額應該保持不變;如果有關賬戶金額的資料儲存在分散式系統的多個不同的副本,則這些副本的資料應該一樣。

從這個意義上,不管是單機資料庫還是分散式儲存系統還是微服務架構下的分散式應用,對一致性的追求本質上是一樣的:在滿足系統本身約束的前提下,對於發生的業務操作及其執行狀態的一致性描述。只不過由於分散式系統資料的分散式儲存以及網路通訊狀況的複雜,使得分散式系統要保持資料一致性相比單機應用要考慮更多複雜的因素,實現也要困難的多。很多文章把它們做了嚴格的區分,個人覺得很沒有必要,也不利於對於一致性的正確理解,從哲學的角度看,是割裂了事物共性和個性之間的聯絡。

2.分散式一致性模型

就好像單機資料庫中為事務的隔離性設定了不同的級別,分散式系統中對資料的一致性級別也有分類。總的來說可以分為強一致性和弱一致性兩大類,弱一致性中又可以繼續細分為最終一致性,因果一致性,會話一致性,單調讀一致性和單調寫一致性等多種,不過弱一致性中只有最終一致性比較重要,其他的可以暫時忽略。

• 強一致性
  以帶多副本的分散式儲存系統為例,所有連線到分散式系統的客戶端看到的某一資料的值都是一樣的。當某個客戶端修改了這個值,後續的所有客戶端都能讀取到這個更新的值,並且所有的更新操作都在這個新的值的基礎上進行,直到這個值被再次修改,如下圖所示,在A修改X前所有客戶端都能讀取到X的值為1,在A將X修改為2之後,所有客戶端都能讀取到這個更新後的值。
  

• 最終一致性
  所有不能滿足強一致性要求的都稱為弱一致性,而最終一致性是其中比較強的一種。在最終一致性模型下,當資料項X被修改後,客戶端並不一定能馬上看到這個更新後的值(有些可能讀取到了新值,有些讀取到的可能還是舊值),但是在一段時間後,所有客戶端都能讀取到這個更新後的值並進行相關操作。最終一致性模型下,分散式資料最終能達到一致,但是需要經過一段時間,這段時間稱為不一致視窗。
  如下圖所示,在A將X修改為2後,在不一致視窗內只有B能讀取到X=2,其他客戶端讀取到的依舊是X=1。但是在不一致視窗後,所有客戶端都能讀取到X=2。
  

3. 追求強一致性的約束——CAP定理

嚴格意義上來講,真正的一致性模型只有一種——強一致性,這也是一種理想化的模型。它為分散式資料維護了完全一致的檢視,使得一旦修改了資料後,所有客戶端能夠馬上看到這個更新後的值並基於這個新值進行後續的操作,使得我們操作分散式資料和操作本地資料一樣。在分散式系統中要實現一致性需要考慮其他因素,比如可用性和分割槽容忍性,而這些因素相互有制約,這種制約關係在CAP定理中被很好的進行了描述。

CAP是"Consistency","Availabilty","Partition Tolerance"的簡稱,分別代表了:強一致性,可用性和分割槽容忍性,它們的含義分別如下:

• 強一致性:在分散式系統同一份資料有多副本的情況下,對於資料的操作效果和只有單份資料一樣。
• 可用性:客戶端在任何時刻對資料的讀/寫操作都應該保證在時限內完成。
• 分割槽容忍性:當分散式系統出現網路分割槽,不同分割槽間的機器無法進行網路通訊時,系統仍然能夠繼續工作。

CAP定理的內容:對於一個分散式系統,無法同時實現強一致性,可用性和分割槽容忍性,即CAP三要素不可兼得。

3.1 如何理解CAP三要素不可兼得

由於網路的不可靠性,網路分割槽的情況不可避免的會發生,當出現網路分割槽時,不同分割槽的機器無法進行通訊。分散式系統必須能夠在出現網路分割槽的情況下繼續工作,因而對於分散式系統而言,P即分割槽容忍性是必須要具備的要素,那麼問題就轉化為了,在系統滿足分割槽容忍性的前提下,為什麼強一致性和可用性不可兼得。
假設資料項A的三個副本分別儲存在不同的物理節點,在某一時刻,系統狀態如下圖所示

當客戶端將節點1上的A修改為2後,系統出現了網路分割槽,其中節點1和節點2在一個網路分割槽中,而節點3在另一個分割槽中

當有客戶端嘗試讀取節點3上的A值時,系統將面臨兩難困境

• 系統等待節點3從節點1同步A的值,待資料一致後再返回客戶端響應,但是因為節點3和節點1不在一個分割槽中,雙方無法進行通訊,導致系統無法在限定時間內給客戶端返回讀取結果,這明顯不符合可用性的要求。
• 系統立即返回一個A=1的舊值給客戶端,由於A的值在不同節點上不一樣,導致一致性的條件被破壞。

因而,對於滿足分割槽容錯性的系統而言,強一致性和可用性的要求難以同時被滿足。其實這是很容易理解的,即使沒有網路分割槽,因為不同節點上的資料需要經過網路通訊來保持一致性,這個過程本身就比較花時間,當需要在給定很短的時限內基於客戶端響應時,對於一致性的保證自然就比較弱。

3.2 如何正確理解CAP定理

• 對於分散式系統而言CAP三要素不可兼得,但並不意味著在任何時刻都必須從中做出取捨,或者在構建分散式系統之初就選擇其中兩個而放棄另一個,這種看法具有片面性。
• 由於網路分割槽出現的可能性非常小,系統在正常執行的情況下還是應該兼顧AC兩者,在進入網路分割槽模式後才需要對P進行保證,從A和C中選擇犧牲一個。
• A和C並不是一個硬幣的兩面,只能選擇其中一個;A和C應該看成天平,系統可以選擇向哪邊傾斜,但另一邊也應該一定程度的保留。
• 對於A和C之間的選擇,不應該粗粒度的整個系統級別進行選取,而應該針對系統中的不同子系統,針對性的採取不同的取捨策略。

4. 一致性的妥協——最終一致性和Base原則

由CAP定理可知,在分散式系統中過於追求資料的強一致性將導致可用性一定程度被犧牲,這意味著系統將不能很好的響應使用者的請求,這會一定程度影響使用者體驗。因而對於大部分散式系統而言,應當在保證系統高可用的前提下去追求資料的一致性,BASE原則正是對這一思想的描述。

• BA(Basically Available)
  基本可用:系統在絕大部分時間應處於可用狀態,允許出現故障損失部分可用性,但保證核心可用。

• S(Soft State)
  軟狀態:資料狀態不要求在任何時刻都保持一致,允許存在中間狀態,而該狀態不影響系統可用性。對於多副本的儲存系統而言,就是允許副本之間的同步存在延時,並且在這個過程中系統依舊可以響應客戶端請求。

• E(Eventual Consistency)
  最終一致性:儘管軟狀態不要求分散式資料在任何時刻都保持一致,但經過一定時間後,這些資料最終能達到一致性狀態。

BASE理論的核心思想是:把分散式系統的可用性放在首位,放棄CAP中對資料強一致性的追求,只要系統能保證資料最終一致。

4.1 CAP,BASE以及ACID的關係

CAP描述了對於一個分散式系統而言重要的三要素:資料一致性,可用性,分割槽容錯性之間的制約關係,當你選擇了其中的兩個時,就不得不對剩下的一個做一定程度的犧牲。BASE和ACID都可以看做是對CAP三要素進行取捨後的某種特殊情況

• BASE強調可用性和分割槽容錯性,放棄強一致性,這是大部分分散式系統的選擇,比如NoSQL系統,微服務架構下的分散式系統
• ACID是單機資料的事務特性,因為不是分散式系統無需考慮分割槽容錯,故而是選擇了可用性和強一致性後的結果。
  它們之間的關係如下所示
  

5. 分散式系統的冪等性

冪等的概念來自於抽象代數,比如對於一元函式來說,滿足以下條件

即可稱為滿足冪等性。在電腦科學中,一個操作如果多次執行產生的影響與一次執行的影響相同,這樣的操作即符合冪等性。在分散式系統中,服務消費方呼叫服務提供方的介面,多次呼叫的結果應該與一次呼叫的結果一樣,這正是分散式環境下冪等性的語義。為什麼冪等性對分散式系統而言如此重要？因為在分散式環境下,服務的呼叫一般採用http協議或者rpc的方式,即雙方需要通過網路進行通訊,而因為網路故障或者訊息超時的存在,可能服務消費方已經成功呼叫了服務提供方的服務介面,但是消費方並沒有收到來自對方的成功響應,導致消費方以為服務呼叫失敗從而再次進行呼叫,也就是說網路的不可靠性導致了服務介面被多次呼叫的可能。分散式系統必須保證在這種情況下,即使介面被多次呼叫,它對系統產生的影響應該與該介面只被呼叫一次的結果一樣。

6.微服務架構的分散式一致性和冪等性問題

6.1 微服務架構下的分散式一致性問題

微服務架構下,處理一個業務請求可能需要呼叫多個微服務進行處理,以前面的下單並支付場景為例,完成該業務請求需要先後呼叫訂單微服務的下單介面和支付微服務的支付介面,只有這兩個介面都呼叫成功,該業務操作才算執行成功。那麼微服務架構中是如何保證同屬於一個業務單元的多個操作的原子性以及保證分散式資料一致性的?——答案是分散式事務。

分散式事務是指事務的參與者、支援事務的伺服器、資源伺服器以及事務管理器分別位於不同的分散式系統的不同節點之上

並且根據遵循的一致性原則不同,可以分為剛性分散式事務和柔性分散式事務兩大類。

• 遵循ACID原則的剛性事務
  剛性事務追求資料的強一致性,比如基於兩階段提交和三階段提交的分散式事務就屬於剛性事務,通過分散式事務,客戶端可以看到描述業務執行狀態的多個數據的一致性檢視,比如下單並支付這個業務操作,客戶端要麼能夠同時查詢到下單和支付成功的資訊,要麼能夠同時查詢到下單和支付失敗的資訊,其他不一致的情況對於客戶端而言都是不可見的。比如下單成功,支付還在處理;下單成功,支付失敗,下單記錄正在回滾。也就是說,當訂單資料和支付資料不一致時,對於客戶端的訪問請求應該予以拒絕。
  

這當然導致了系統可用性的降低,加上剛性事務實現時會導致同步阻塞的問題,鎖定資源等問題,會極大的影響系統的吞吐量和設計彈性,所以實際上微服務架構不太會採用剛性事務。

• 遵循BASE原則的柔性事務
  柔性事務只對資料的最終一致性進行保證,允許系統存在一定時間的資料不一致,比如訂單記錄已經被更新但是支付記錄還沒落地時,又比如訂單記錄更新成功但是支付失敗訂單記錄回滾的過程。
  

在這個不一致視窗內,系統允許客戶端對不一致的資料進行訪問,因而系統的可用性相比而言會更好,加上其擴充套件性良好以及吞吐量的優勢,一般微服務架構下都會採用柔性事務。柔性事務有多種不同的實現方式,比如基於可靠事件的模式,基於補償的模式,基於Sagas長事務的模式等,具體的實現原理以及優缺點對比就放到下一篇在詳解解釋。

6.2 微服務架構下的冪等性問題

6.2.1 冪等性場景

在微服務架構下,不同微服務間會有大量的基於http,rpc或者mq訊息的網路通訊,介面的重複呼叫以及訊息的重複消費可能會經常發生,比如以下這些情況

• 呼叫訂單建立介面,第一次呼叫超時,呼叫方又嘗試了一次,但其實第一次呼叫已經成功,只是呼叫方沒有及時收到響應。
• 訂單支付完成後,需要向MQ傳送一條訊息,但該訊息重複傳送了兩條。
• 網路波動導致服務提供方的介面被呼叫了兩次。
• 使用者在使用產品時,無意地觸發多筆交易。
• 某些未關閉的重試機制。

微服務架構應該具有冪等性,當介面被重複呼叫時,訊息被重複消費時,對系統的產生的影響應該和介面被呼叫一次,訊息被消費一次時一樣。

6.2.2 CRUD操作的冪等性分析

• 新增請求:不具備冪等性
• 查詢請求:重複查詢不會影響系統狀態,查詢天然具備冪等性
• 基於主鍵的更新請求
  要更新的值依賴於前值,不具備冪等性。比如update goods set number=number-1 where id=1
  要更新的值不依賴於前值,具備冪等新。比如update goods set number=newNumber where id=1
• 刪除請求
  基於主鍵的物理刪除(delete)刪除具備冪等性
  基於主鍵的邏輯刪除(update)也具有冪等性

總結:通常只需要對新增請求和更新請求作冪等性保證。

6.2.3 如何解決冪等性問題

• 全域性唯一ID
  根據業務生成一個全域性唯一ID,在呼叫介面時會傳入該ID,介面提供方會從相應的儲存系統比如Redis中去檢索這個全域性ID是否存在,如果存在則說明該操作已經執行過了,將拒絕本次服務請求;否則將相應該服務請求並將全域性ID存入儲存系統中,之後包含相同業務ID引數的請求將被拒絕。

• 去重表
  這種方法適用於在業務中有唯一標識的插入場景。比如在支付場景中,一個訂單隻會支付一次,可以建立一張去重表,將訂單ID作為唯一索引。把支付並且寫入支付單據到去重表放入一個事務中,這樣當出現重複支付時,資料庫就會丟擲唯一約束異常,操作就會回滾。這樣保證了訂單隻會被支付一次。

• 多版本併發控制
  適合對更新請求作冪等性控制,比如要更新商品的名字,這是就可以在更新的介面中增加一個版本號來做冪等性控制

boolean updateGoodsName(int id,String newName,int version);

資料庫更新的SQL語句如下

update goods set name=#{newName},version=#{version} where id=#{id} and version<${version}

• 狀態機控制
  適合在有狀態機流轉的情況下,比如訂單的建立和付款,訂單的建立肯定是在付款之前。這是可以新增一個int型別的欄位來表示訂單狀態,建立為0,付款成功為100,付款失敗為99,則對訂單狀態的更新就可以這樣表示

update order set status=#{status} where id=#{id} and status<#{status}

• 插入或更新
  在MySQL資料庫中，如果在insert語句後面帶上ON DUPLICATE KEY UPDATE 子句，而要插入的行與表中現有記錄的惟一索引或主鍵中產生重複值,則對舊行進行更新;否則執行新紀錄的插入。
  我們可以利用該特性防止記錄的重複插入,比如good_id和category_id構成唯一索引,則重複執行多次該SQL,資料庫中也只會有一條記錄。

insert into goods_category (goods_id,category_id,create_time,update_time) 
       values(#{goodsId},#{categoryId},now(),now()) 
       on DUPLICATE KEY UPDATE
       update_time=now()

7. 參考資料

《大資料日知錄》
《微服務設計原理與架構》
如何保證微服務介面的冪等性