萬達集團李明昊：地域分散式系統設計與實踐

導語： 本文根據李明昊老師在2018年5月10日【第九屆中國資料庫技術大會(DTCC)】現場演講內容整理而成。

李明昊 萬達網路科技集團 資深架構師

現任萬達網路科技集團資深架構師，BI（商業智慧）團隊技術負責人。之前曾在百度，360等公司參與設計研發過多個海量資料分散式儲存系統，包括百度公有云服務的底層分散式儲存系統MolaDB，360雲盤的底層分散式儲存系統Bada等。

摘要： 本次分享，深入剖析了主流的一致性協議paxos，raft等的歷史淵源和設計細節，闡述了它們的優缺點與適用場景；並結合公司的實際場景，對raft協議做了改進，使自研的分散式儲存系統可以執行於這個具體環境之上，同時兼顧效能，可靠性與硬體、網路成本。

大綱：

提出問題

分析問題

解決問題

經驗總結

正文

1． 提出問題

萬達在全國具有200+的實體廣場，每個廣場具備自己的內部機房。包括路由器，無線熱點，主機，防火牆等硬體資源。當使用者進入廣場內部時，手機會透過熱點自動連入廣場內部區域網系統。

但這些廣場機房的服務質量遠達不到專業資料中心的服務質量。廣場內部接近區域網環境，廣場之間接近廣域網環境。

如果我們能有效的利用廣場內部硬體、網路資源，將使用者或商品的一部分資料存入廣場內部機房，並做合適的計算加工，使用者將享受到本地計算與本地儲存的體驗，同時降低了硬體成本。但必須想辦法解決小機房服務質量不達標的問題。

2． 分析問題

2.1瞭解必要的理論體系

歷史脈絡

這是我擷取的一個分散式和資料庫理論的重要事件時間軸。透過這個時間軸我們可以總結出如下結論：

1、  計算機與網際網路技術起源於戰爭的需要。

2、以Jim Gray為代表的資料庫技術和以Leslie Lamport為代表的分散式技術逐漸融合。

這裡面涉及到兩個重要的人物，一個是Jim Gray。大約在七十年代，Jim Gray寫了一篇文章，文章抽象出了資料庫事務處理的概念，包括兩階段提交、日誌以及其他事務處理的ACID概念。

另外一個人是Leslie Lamport，他在1978年寫了一篇論文，描述了邏輯時鐘的概念，後續的很多分散式領域都是基於他的論文建立的，包括1990年Leslie Lamport自己提出的paxos協議。

CAD猜想

CAD是2000年Eric Brewer在UC Berkeley提出來的，並在2002年得到了證明。在分散式領域，CAD理論對我們的影響非常大。

ACID、CPA兩個C有什麼不同？

ACID裡面的C指的是“Consistency（始終如一的）”，指的是同一份資料，不管進行怎樣的操作始終保持一致性或者受約束的狀態。CPA裡面的C指的是“Consensus（共識的）”，指的是多份資料。當然這個說法也不是特別嚴謹。

如下圖所示：

Consistency主要表現一種約束性，就比如圖片上的一個五角星可以正好的放進左邊的矩形框裡，即可以說它是一致的。但是下面的五邊形無法放進左邊的矩形框裡，它不符合約束，即非一致性。

對於Consensus（共識的），如上圖，五個一樣的五角星保持一致即共識的，如果中間的一個五角星變成五邊形，即非共識、非一致。

關於分散式裡的“一致性”，Amazon-com的CTO Werner Vogels又進一步進行了細分。Werner Vogels把一致性又分成了強一致性、弱一致性、最終一致性。最終一致性又分成因果一致性、讀寫一致性、會話一致性、單調讀一致性、單調寫一致性。

如何劃清問題邊界？

在六七十年代的時候，計算機剛被發明出來，底層有作業系統、檔案系統、磁碟。那時大家如果想把銀行轉賬的交易放在計算機系統裡，想基於這個作業系統直接開發一個銀行轉賬的賬務系統，幾乎是一個不可能完成的任務。

Jim Gray提出了一個概念，在低層複雜的系統上構造一個事物層，透過複雜的環境抽象出一個簡單的事物系統，事物系統本身保證ACID，業務系統直接針對ACID的事物系統進行操作，這樣應用系統就會簡化很多。

業務邏輯簡單了，但ACID又如何保證呢？

Jim Gray寫過一本書叫做《事物處理》，這本書對事物系統有很深的描述。書中有一章特別強調機率的作用，有一個結論是這樣描述的： “絕對的ACID是不存在的，只是在某種機率上得到了保證。”深刻的強調了機率的重要性。

於是我們得到了一個方法：對於特別複雜的環境，以某種機率抽象出一個簡單的城市，然後假設基於這個城市去解決問題，關注的重點在於假設的環境而不是真實的環境。

那麼除了單機的抽象，分散式領域裡的抽象又是什麼樣的呢？

Leslie Lamport提出來一個分散式領域裡的模型假設：

1. 網路中包含多個主機

2. 每個主機包含若干程式與磁碟

3. 程式間透過網路包通訊

4. 網路包可能會重複，丟失，亂序，但內容不會出錯

5. 程式可能會重啟

6. 磁碟可能會損壞，導致資料丟失，但資料不會出錯

7. RTT一般在1ms之內（後加）

基本上就是一個區域網的環境，其實近十幾年來，我們做的分散式系統大部分都是基於這種假設去構建的一種“非拜占庭的環境”。

拜占庭問題

對於拜占庭問題，可以簡單的理解為：承諾與實際表現不相符

比如，網路包資料出錯、磁碟資料出錯、程式出現bug等。我們做設計的時候，如果考慮到拜占庭問題，系統將會特別複雜，幾乎是不可能完成的設計。但是拜占庭問題在實際的環境中又真實存在，所以怎樣去解決呢？

基於剛才所說的機率問題，我們可以透過其他方式在一定的機率上解決拜占庭問題，但不能影響我們基於非拜占庭環境的架構設計。

比如，網路包或者磁碟出錯，我們加一些校驗碼，但是可能會給系統增加負擔，如何去抉擇還要基於實際情況，只要機率足夠大滿足我們的需求就足夠。

 

也就是我們在一個拜占庭的環境裡抽象出一個非拜占庭環境，然後基於非拜占庭環境做設計。

關於CPA的誤解

CPA理論對現在的分散式設計有很大影響，但是可能存在一些誤解。

2000年，Eric Brewer教授在UC Berkeley提出了CAP猜想：在一個分散式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分割槽容錯性）這三個基本需求，最多隻能同時滿足其中的2個。

但是後續很多人對CAP猜想產生了質疑，有人認為CAP定理不正確，但也有人支援該理論，認為該理論可以解決CAP。在2002年，Eric Brewer教授再一次重新解釋了CAP。

這裡存在一個很大的誤解就是很多人將CAP理解成CA、AP或者CP。實際上CAP理論不是一個特別嚴格的理論，它只是一個工程領域對分散式系統設計思維框架的指導。大家不要把CAP理論看成一個枷鎖，它不是絕對的，是有一些中間狀態的。

比如，它的可用性定義為在可接受的時間內給出反饋結果，可接受的時間就是一個很主觀的概念，取決於實際場景的需要。

對於結論，我們不需太糾結，以滿足實際需求為標準。

2.2實體場測，抽象問題模型

   回到我們最初的問題，萬達在全國具有200+的實體廣場，那麼這200多個廣場是什麼樣的呢？

這是一個全國多個廣場的真實測試資料，最終彙總如下：

1. 網路中包含多個主機

2. 每個主機包含若干程式與磁碟

3. 程式間透過網路包通訊

4. 網路包可能會重複，丟失，亂序，但內容不會出錯

5. 程式可能會重啟

6. 磁碟可能會損壞，導致資料丟失，但資料不會出錯

7. RTT同廣場1ms以下，同城10ms，跨城市幾十ms

得到的結論是同城接近區域網，跨城接近廣域網，供電系統弱於專業機房，機房斷電機率高於專業機房，冷卻系統弱於專業機房，機器重啟機率高於專業機房。

2.3協議選型與改造1

Paxos類協議

一個很重要的協議就是Paxos協議，現今我們很多的強一致協議基本都是基於Paxos協議。

多個節點如何就一個值達成一致？一個主要方式是value取得大多數acceptor的認可。

多個節點就一個值達成一致有什麼用？用處之一是多個節點選主。

另一個用處就很重要了，它由Leslie Lamport提出。Leslie Lamport表示：假設有多臺機器，每臺機器裡有一個順序日誌，另外有一個狀態機，然後我們透過Paxos協議保證順序日誌一致。順序日誌每條條目是一個操作，把日誌入到狀態機裡，這就是一個非常有用的模型。

比如，狀態機是一個儲存引擎，那麼它就是一個分散式資料庫，如果我們把狀態機定義成其他，那麼它就是其他的一個系統。這就是所謂的Multi-Paxos。Multi-Paxos 只是一個思路，很多細節並沒有完善，所以落實到實踐會很難。

2014年，史丹佛大學釋出了一個Raft協議，這個協議描述的很精確，包括日誌如何合併、如何入到狀態機、多個日誌之間如何同步等。對於實現一個真正的系統來說，Raft協議發揮了很大作用。

我們假設採用Paxos模型（Raft模型），在北京的通州、石景山和愛琴海的三個機房裡，執行一個Raft Group，還有Leader和Follower，它們的寫是透過組進行的，讀是任意讀的。看起來似乎沒有問題，但是如果這三個節點在不同的地域可能就存在問題了。比如三個節點分別在上海、北京和瀋陽，資料可能會發生異地寫，或者異地的日誌同步，在廣域網裡面這種情況可能不會被接受，因為丟包率比較大、時延比較高。所以如何解決呢？

一個方法是我們不要把Raft組裡面的幾個節點放到異地，保證Raft Group在一個近似區域網的環境。這樣便解決了Raft Group資料同步的問題，但仍然沒有完全實現本地讀寫。

為了解決這個問題，我們抽樣統計了使用者的對某條資料的讀寫地點，發現99%以上的讀寫都發生在資料所在的同一個城市。

    基於這個假設我們便可以對這個協議進行改造。

我們對Raft組裡的每一個資料副本加一個歷史訪問資訊，資料執行過之後，我們就能知道這個資料主要的訪問點在哪，然後根據它的主要訪問點把Raft Group裡的副本分配到應該在的地方，這樣就能夠保證99%的讀寫都是本地的。

方法總結：

1. 根據歷史訪問規律，對資料增加歸屬地資訊

2. 99%以上的讀寫享受本地計算和本地儲存的收益

3. 對資料的讀操作，提供強一致和最終一致兩種介面。強一致讀歸屬地機房，最終一致讀

本地機房。

4. 系統統計使用者的歷史訪問規律，對歸屬地資訊做自適應的修改。

優勢是99%以上的讀寫享受本地操作待遇。劣勢是受限於業務場景，不是一個“普適”的系統。也就是說它可能只是針對於線下人類活動的物理規律抽象出的一個模型，並不適合所有的場景。

該如何解決呢？我們思考一下：

所謂的“最佳化”本質上是針對特定場景下的訪問規律在時間和空間兩個維度做自適應和更精確的排程。目前我們能做到的是分析使用者特定場景下的規律，針對這個規律做一些最佳化。一般的最佳化都要基於一個具體的場景，然後觀察在時間和空間兩個維度上是否能夠做複用。

最終一致類協議

另外一種思路是Dynamo亞馬遜的VectorClock。每一個點都可以讀寫，它讀寫的時候會帶一個時間戳，這個時間戳可能是物理的時間戳也可能是邏輯的時間戳，在讀的時候對這個時間戳做一個merge，最後取得一個最新的資料。

詳細內容大家可以參考下圖片中的兩個論文。這裡我強調一下第二篇論文《Time Clocks and the Ordering of Events in a Distributed System》，是1978年由Leslie Lamport發表的，論文闡述了邏輯時鐘的概念。

如果我們真的可以做到在每一臺機器上加一個時間戳，那麼實現所有的系統都不是問題了。但是不同的機器時間是不同的，它們之間會存在誤差，每臺機器的時鐘CPU裡的時鐘程式都可能會有誤差。這是物理時鐘存在的問題。

待探索

基於剛才的分析，我們是否還可以在進行一些改進呢？

比如我們對每一條資料加入了一個歷史訪問資訊，我們是否可以針對這些歷史訪問資訊做一些挖掘，然後把這些資料自適應到全國的某一個廣場某一臺機器的某一臺磁碟上去？甚至在使用者去某一個廣場之前，就把資料預測出來然後提前排程過去？這樣天馬行空的想法是否可行我們還需進一步探索。

問題的關鍵點在於它不只是一個純線上的活動，它是一個線上線下融合的系統。使用者線下的物理行動是有一定規律可循的，我們可以對線下的規律進行挖掘，然後對線上的資料做一些適配。

當然這也只是一個想法，是否可靠，尚待研究和實踐檢驗。

3．解決問題

為了解決問題，我們最終的選擇是Raft Group 掛Slave這種方式，針對歷史資訊把資料排程到合適的地方。

但是又引發一個新的問題，實現一個生產級別的Paxos庫，並不是一件容易的事。你在編碼的時候會發現很多的問題，比如Paxos裡的成員怎樣做抽象？到底選擇多執行緒還是多程式？用不用流水線？怎樣充分利用CDO？

好在我們國內有很多開源的實現，比如騰訊的PhxPaxos庫、阿里的X-PAXOS架構等。

系統設計與實踐流程

最後我們得到這樣一個流程：

面對一個特別複雜的軟硬體環境，我們要先做測試然後建模、協議選型，如果選好的型不完全符合我們在進行改造，然後進行架構設計，最後測試、上線。

4．經驗總結

1.理論決定上限，經驗決定下限。

2.架構師的抽象思維能力很重要。

3.天馬行空的思考，腳踏實地的實踐。

4.實踐！實踐！實踐！