華爲資深架構師：Cloud Native架構一致性問題及解決方案

內容來源：2017年12月2日，華爲資深架構師王啓軍在「NJSD互聯網架構峯會」進行《Cloud Native架構一致性問題及解決方案》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2092 | 6分鐘閱讀

嘉賓演講視頻及PPT回顧：suo.im/tPQXc

摘要

在開發或軟件架構的過程當中，常常會遇到一致性的問題，那麼如何去解決權衡。咱們先從理論入手，而後進一步討論強一致性和最終一致性的解決方案。

基礎理論

Cloud Native的組成

關於這個概念不少人都有不一樣的見解，我認爲Cloud Native主要是由架構、組織、工程三部分組成的。大部分公司可能主要是關注架構部分，其實組織方面也是很是重要的，它的價值在於可以實現更快的速度、更好的用戶交互體驗以及更妥當的系統。

Cloud Native-架構

Cloud Native架構主要包含兩部分，一個是基礎設施這塊，另外一個是微服務架構方面。圍繞着微服務又擴展出了可用性、一致性以及擴展性部分。

一致性的分類

在學術界通常將一致性分爲兩類，一類是以數據爲中心，一類以用戶爲中心。以數據爲中心的，不管有多少個節點都是從總體上來看一致性。而以用戶爲中心，是從客戶端的節點來看待一致性的。

嚴格一致性

嚴格一致性要求任何寫操做都能馬上同步到其餘全部進程，任何讀操做都能讀取到最新的修改。好比說有三個節點，當某一個節點的數據a變成1的時候，另外兩個節點的a就須要同步改變。

順序一致性

嚴格一致性須要有一個全局時鐘才能實現，可是這個全局時鐘是很難實現的。因而順序一致性放棄了它，轉而改用分佈式邏輯時鐘來實現。

順序一致性是指全部的進程以相同的順序看到全部的修改，讀操做未必能及時獲得此前其餘進程對同一數據的寫更新，可是每一個進程讀到的該數據的不一樣值得順序是一致的。

因果一致性

因果一致性是一種弱化的順序一致性，若是兩個數據之間存在因果關係，那麼在後續的全部操做都應該基於這一關係。全部的進程必須以相同的順序看到具備潛在因果關係的寫操做。不一樣進程能夠以不一樣的順序看到併發的寫操做。

如何實現強一致性

兩階段提交

提到強一致性，相信你們首先想到的就是兩階段提交。也就是整個交互過程分爲兩個階段。第一階段協調者先向參與者提問是否能夠提交，同時鎖定數據，第二階段參與者提交。

這裏面存在幾個問題，第一階段鎖定數據以後，若是協調者掛掉了，將沒有角色去通知參與者是否應該提交，這個數據會被一致鎖定。若是第二階段參與者1提交成功，參與者2提交失敗，此時協調者不知道該如何處理，由於參與者1已經提交成功，外部能夠訪問了。

三階段提交

三階段提交實際上是把兩階段提交的第一階段分爲了兩個階段，這是爲了下降原來第一階段的死鎖的機率。三階段的第一階段在詢問是否提交的時候並無鎖定數據，而是在準備提交的時候才鎖定數據。

實際上使用三階段提交，性能上會有更多的消耗，交互會愈來愈多，可擴展性也不好。

如何實現最終一致性

調試失敗怎麼辦

假設有一個服務M須要去調用另外的兩個服務A、B，在調用的過程當中失敗了話，最多見的作法就是重試。這時就須要去考慮重試的次數、超時時間、間隔時間以及間隔時間的衰減度，而重試沒有作好的話就很容易形成系統的負擔。

改進方案

其實徹底能夠添加一個日誌，而且能夠收集到遠端。經過收集系統收集到分佈式文件系統內，這樣就能夠不斷的去檢測這個系統是否有問題。

還有一種解決方案——可靠事件，服務在調用失敗後，經過另外一種方式將數據傳輸到消息隊列，而後要被調用的服務去讀取消息隊列。

對於最終一致性來講，要麼所有成功，要麼所有失敗。

如何保證寫後讀一致

這須要在寫消息的同時，去寫一個事件日誌。若是一旦失敗的能夠經過補償服務不斷的遍歷事件的這張表，最終拿到消息再去發送時間

長事務一致性

Sage事務模型

Sgae是一個比較早期的事務模型，它的核心思想是將一個長事務拆分爲多個本地事務。而process manageer就是負責處理事務拆封的，而後再去調用不一樣的服務。

這是一個具體的事務處理流程，這裏面須要定時的去作檢查判斷是否失敗，失敗了就要發送消息，正向調用時寫回退日誌。

TCC

在作系統的時候你會發現服務是很容易的去擴展的，數據庫每每會出現瓶頸，那麼如何去平衡壓力，有不少的解決方案，TCC就是其中的一種。

TCC的優點在於將數據庫的操做，放到業務層處理，平衡了數據庫的壓力。但同時也付出了必定代價，它增長了業務的複雜度，須要提供相應的Try、Confirm、Cancel接口，並且接口仍是冪等性的。

如何保障冪等

第一種就是經過數據加鎖的方式，第二種是分佈式鎖，不過這種鎖不能保障絕對一致性，第三種方案能夠去作惟一約束，在惟一約束無效的狀況下能夠增長流水錶這也是第四種方案。