分佈式系統架構的基本原則和實踐概述

時間 2019-11-11

原文原文鏈接

1、分佈式系統遵循幾個基本原則

1. CAP原理

CAP Theorem，CAP原理中，有三個要素：node

一致性(Consistency)
可用性(Availability)
分區容忍性(Partition tolerance)

CAP原理指的是，在分佈式系統中這三個要素最多隻能同時實現兩點，不可能三者兼顧。所以在進行分佈式架構設計時，必須作出取捨。而對於分佈式數據系統，分區容忍性是基本要求，不然就失去了價值。所以設計分佈式數據系統，就是在一致性和可用性之間取一個平衡。對於大多數web應用，其實並不須要強一致性，所以犧牲一致性而換取高可用性，是目前多數分佈式數據庫產品的方向。web

從客戶端角度，多進程併發訪問時，更新過的數據在不一樣進程如何獲取的不一樣策略，決定了不一樣的一致性。對於關係型數據庫，要求更新過的數據能被後續的訪問都能看到，這是強一致性。若是能容忍後續的部分或者所有訪問不到，則是弱一致性。若是通過一段時間後要求能訪問到更新後的數據，則是最終一致性。但web應用也有例外，好比支付寶系統，就要求數據（銀行帳戶）的強一致性，並且面對大量淘寶用戶，可用性要求很高，所以只能犧牲數據的分區冗餘。這一點也曾在和支付寶工程師交流時，獲得驗證。算法

2. C10K問題

分佈式系統另外一個理論是C10K問題，即系統的併發用戶增長1萬（customer ten thousand，過去一臺服務器承載假設爲1萬用戶，如今平均3～5萬），是否意味着增長一臺機器就能解決問題？答案一般是否認由於這涉及到系統的應用架構問題----串行系統和並行系統的架構和性能提高的關係：串行系統通常設備越多，性能成一條向下彎曲的曲線，最差狀況，可能性能不增反降；而並行分佈式系統設備越多，性能是正比例線性增加的直線mongodb

3. 串行系統和並行系統的可靠性問題

一個大系統通常都有超過 30 個環節（串行）：若是每一個環節都作到 99% 的準確率，最終系統的準確率是 74%; 若是每一個環節都作到98%的準確率，最終系統的準確率 54%。一個 74% 的系統是可用的（有商業價值的），一個 54% 的系統僅比隨機稍好一點，不可用。這就是作大系統的魅力和挑戰！而以上描述只是各模塊串行系統所遇到的問題數據庫

若是是並行系統，準確率=1-(1-A)^B ，其中A是單個模塊準確率，B是並行模塊個數如系統中每一個模塊的準確率是70%，那麼3個模塊並行，總體準確率=1-0.3^3=97.3%,若是是4個並行，準確率=1-0.3^4=99.19%,我在想這就是負載均衡靠譜的數學原理 5個9或6個9的QoS必定是指數思惟的結果，線性思惟等於送死後端

而對系統單一模塊優化，準確性和可用性提高一個百分點，越接近100%，難度越大，投入成本越不可控（系統熵永不爲零）所以可靠性系統必然選擇並行分佈式做爲架構的基本方法。服務器

從數據的存儲角度，多份冗餘也是可靠性保障的一個方法。分佈式存儲的冗餘備份常規是3份（aws就這麼幹的），古埃及的羅塞塔rosetta石碑用古埃及象形文字、埃及拼音和古希臘文三種文字記錄一段歷史，就算象形文字缺了一部分，沒人能看懂，也能破譯補全，這大概也是raid5的思想起源吧網絡

2、分佈式系統架構的實踐概述

1. 分佈式存儲架構

** 分佈式存儲架構現階段有3種模式 **架構

1.1 物理存儲採用集中式，存儲節點採用多實例的方式

例如NFS掛載SAN、NAS併發

1.2 帶有中央控制器的分佈式存儲

luster、moosefs、googlefs、TFS(taobao FS)

分佈式存儲通常特徵是具有2個角色metadata server和storage node，將文件的元數據（描述數據的數據，如文件位置、大小等等）和數據塊文件分開存儲其中metadata server除保存文件的元數據外，還維護存儲節點的ip、狀態等信息。

luster架構

MDS--meatadata server
MDT--metadata target
OSS--obj storage server
OST--obj starage target 其中MDT和OST是能夠掛在NAS等中央存儲上的；可見，luster借鑑了上面中央存儲的模式，不管元數據服務仍是節點服務都將服務實例和存儲分離，但進化了一步，將元數據和數據塊分離

luster系統很好解決了數據分佈式存儲，，在超級計算領域Lustre應用普遍，如美國LLNL國家實驗室計算機系統、我國的天河超級計算機系統均採用Lustre搭建分佈式存儲系統。Lustre在全球排名前30個超級計算機系統中有15個在使用。

但有一個問題，就是metadata server的SPoF（single point of failure）問題，即單點故障；一旦metadata server掛了，整個集羣也就掛了。實際應用中，是有解決方案的，如dell的官網有個pdf，就是採用heart beat和drbd網絡raid的方式，啓動2個實例，再如和keepalived一塊兒組成故障轉移的方案等等，能夠本身試試

moosefs架構

moosefs架構和luster很類似，但進化了一步，mater（也就是metadata server）能夠有從機備份了，並且能夠多個並且服務實例和存儲放在一塊兒，沒有像luster，自此服務和數據不離不棄了；其實luster也能夠簡化成不離不棄模式，moosefs也能夠學他搞個後端存儲，但隨着雲計算、追求低成本的趨勢，採用SAN這樣存儲設備就太貴了

1.3 去中心化、全對稱的架構（non-center or symmetric）

其設計思想是採用一致性哈希consistent hash算法（DHT的一種實現，關於一致性hash具體參考後面的連接）來定位文件在存儲節點中的位置，從而取消了metadata server的角色

整個系統只有storage node一個角色，不區分元數據和數據塊；典型系統如sheepdog，但sheepdog是爲知足kvm鏡像和類EBS塊存儲而設計的，不是常規的分佈式文件系統，架構以下

爲了維護存儲節點的信息，通常採用P2P技術的totem single ring算法（corosync是一種實現）來維護和更新node路由信息對稱架構有一個問題，採用totem single ring算法的存儲節點數量有限，由於node數量超過1000，集羣內的通訊風暴就會產生（此處更正，應該是環太大，令牌傳遞效率降低，不會產生通訊風暴），效率降低，sheepdog提出了一個解決方案，就是在一致性hash環上作嵌套處理，如圖

1.4 半對稱結構

其實介於1.2metadata server中央控制和1.3全對稱的架構之間還有一種，就是把metadata也作成對稱結構，咱們能夠稱半對稱結構，典型應用如fastdfs，淘寶一大牛fishman寫的，主要用做圖片存儲，能夠實現排重存儲看圖，tracker cluster就是metadata server的角色，實現了對稱架構設計國內幾個大的網站都使用了fastdfs，在實際使用中，發現storage server之間同步數據較慢，一直沒仔細研究

2. 分佈式數據庫架構

分佈式數據庫通常都基於分佈式文件系統實現數據的分片sharding，每中數據庫都有本身的應用特性，就不作介紹，列出幾個典型的應用，供參考 Google的big table，實現數據的追加存儲append，順序寫入快速，不適合隨機讀的場景 hadoop的HBase mongodb hypertable 2010年之前，百度在用，今年infoq的中國qcon，百度的楊棟也講了百度用hypertable的血淚史

###3. 分佈式應用架構分佈式應用架構涉及具體應用場景，設計上除考慮上面的CAP和C10K等等經典分佈式理論，還應根據業務進行權衡。基本的思路是