分佈式系統基礎

1、分佈式系統基礎重要要點：

1     對外提供無狀態節點，內部實現具體有狀態或者無狀態節點邏輯，節點便可以是提供服務，也能夠是存儲數據。

2     拜占庭問題，在分佈式系統中的使用，目的是保證服務可用，而不是找出錯誤的節點，若是。

3     異經常見狀況，機器宕機、網絡異常、消息丟失、消息亂序、數據錯誤、不可靠的TCP。多是收到消息後宕機、也多是處理完成之後機器宕機、處理完成任務後發送確認消息是網絡異常。也有多是發出去的消息丟失，或者發送確認消息時丟失。可能先發送出去的數據後收到

4 分佈式狀態、成功、失敗、超時。超時的狀況，不能判斷是否成功，原有同上。

5 數據存儲在機械硬盤上，隨時有可能發生異常，致使數據沒有能正確存儲。

6 沒法歸類的異常，好比，系統的處理能力時高、時低，的詭異行爲。

7 即便是小几率事件，在天天百萬、千萬、及以上的運算量時也會上升爲大機率事件。

8 副本提升數據的冗餘，提升系統的可用性，可是在使用副本代來好處的同時，也致使維護副本須要成本。如副本的一致性，多個副本一致性，多個副本直接可能到不一致。

9 一致性級別：強一致性、單調一致性，讀取最新數據、會話一致性，經過版本讀取統一值。最終一致性、弱一致性。

 

10 分佈式系統性能指標：吞吐量、響應延遲、併發量；經常使用單位QPS，即每秒鐘的處理能力。高吞吐量會帶來低響應、他們之間是相互制約關係。

11 可用性指標：能夠服務時間和非服務時間的比率和請求的成功和失敗次數來衡量。

12 可擴展性指標：實現能水平擴展，增長低配置的機器便可以實現更大的運算量，和更高的處理能力。

13 一致性指標：實現副本間的一致性能力，一致性須要嚴格考量是否業務容許。

2、分佈式系統原理：

1．  哈希方式，把不一樣的值進行哈希運算，映射到，不一樣的機器或者節點。考慮冗餘的時候能夠把多個哈希值映射到同一個地方。哈希的實現方式，取餘。其實現擴展時，比較困難，數據分散在不少機器上，擴展的時候要從個機器上獲取數據。並且容易出現分佈不均有的狀況。

    常見的哈希，用IP、URL、ID、或者固定的值進行哈希，老是獲得相同的結果。

2．  按數據範圍分佈，好比ID在1~20的在機器A上，ID在21~40的在機器B上，ID在40~60的在機器C上實現，ID在60~100的分佈在機器D上，數據分佈比較均勻。若是某個節點處理能力有限，能夠直接分裂該節點。維護數據分佈的元信息，可能出現單點瓶頸。幾千機器，每一個機器又劃分爲N個範圍，致使須要維護的數據分佈範圍元數據過大，致使可能須要幾臺機器實現。

     必定要嚴格控制元數據量，進可能的減小元數據的存儲。

3．  按數據量分佈，另外一類經常使用的數據分佈方式則是按照數據量分佈數據。與哈希方式和按數據範圍方式不一樣，數據量分佈數據與具體的數據特徵無關，而是將數據視爲一個順序增加的文件，並將這個文件按照某一較爲固定的大小劃分爲若干數據塊（chunk），不一樣的數據塊分佈到不一樣的服務器上。與按數據範圍分佈數據的方式相似的是，按數據量分佈數據也須要記錄數據塊的具體分佈狀況，並將該分佈信息做爲元數據使用元數據服務器管理。

    因爲與具體的數據內容無關，按數據量分佈數據的方式通常沒有數據傾斜的問題，數據老是被均勻切分並分佈到集羣中。當集羣須要從新負載均衡時，只需經過遷移數據塊便可完成。集羣擴容也沒有太大的限制，只需將部分數據庫遷移到新加入的機器上便可以完成擴容。按數據量劃分數據的缺點是須要管理較爲複雜的元信息，與按範圍分佈數據的方式相似，當集羣規模較大時，元信息的數據量也變得很大，高效的管理元信息成爲新的課題。

4．  一致性哈希，構造哈希環，有哈希域[0,10]，則構造3個部分，[1,4)/[4,9)/[9,10),[0,1)/分紅了3個部分，這3部分是一個環狀，增長機器時，變更的是其附近的節點，分擔的是附近節點的壓力，其元數據的維護和按數據量分佈同樣。其將來的擴展，能夠實現多個需節點。

5．  構建映射元數據，創建映射表的方式。

6．  副本與數據分佈，把一個數據副本分散到多臺服務器上。好比應用A的數據，存儲在A、B、C ，3臺機器上，若是3臺機器中，其中一臺出現問題，請求被處理到其餘2臺機器上，若是加機器恢復，還須要從另外2臺機器上，Copy數據，又增長了這2臺機器的負擔。若是咱們有應用A和應用B，各自有3臺機器，那麼咱們能夠把A應用分散在6臺機器上，B應用也分散在6臺機器上，能夠實現相同的數據備份，可是應用存儲的數據被分散了。某臺機器損害，只是把該機器所承擔的負載平均分配到了，另外5臺機器上。恢復數據從5臺機器恢復，其速度快和給各臺服務器的壓力都不大，並且能夠實現機器損害，更換徹底不影響應用。

    其原理是多個機器互爲副本，是比較理想的實現負載分壓的方式。

7．  分佈式計算思想，移動數據不如移動計算，就進計算原則，減小跨進程、跨網絡、等跨度較大的實現，把計算所需的資源儘量的靠近。由於可能出現網絡、遠程機器的瓶頸。

8．  常見分佈式系統數據分佈方式: GFS、HDFS:按數據量分佈；Map reduce 按GFS的數據分佈作本地化；BigTable、HBase按數據範圍分佈；Pnuts按哈希方式或者數據範圍分佈，能夠選擇；Dynamo、Cassndra按一致性哈希；Mola、Armor、BigPipe按哈希方式分佈；Doris按哈希方式和按數據量分佈組合。

3、數據副本協議

1．  副本必定要知足必定的可用性和一致性要求、具體容錯能力，即便出現一些問題也能提供可靠服務。

2．  數據副本的基本協議，中心化和去中心化2種基本的副本控制協議。

3．  中心化副本控制協議的基本思路是由一箇中心節點協調副本數據的更新、維護副本之間的一致性。中心化副本控制協議的優勢是協議相對較爲簡單，全部的副本相關的控制交由中心節點完成。併發控制將由中心節點完成，從而使得一個分佈式併發控制問題，簡化爲一個單機併發控制問題。控制問題，簡化爲一個單機併發控制問題。所謂併發控制，即多個節點同時須要修改副本數據時，須要解決「寫寫」、「讀寫」等併發衝突。單機系統上經常使用加鎖等方式進行併發控制。對於分佈式併發控制，加鎖也是一個經常使用的方法，但若是沒有中心節點統一進行鎖管理，就須要徹底分佈式化的鎖系統，會使得協議很是複雜。中心化副本控制協議的缺點是系統的可用性依賴於中心化節點，當中心節點異常或與中心節點通訊中斷時，系統將失去某些服務（一般至少失去更新服務），因此中心化副本控制協議的缺點正是存在必定的停服務時間。即存在單點問題，即便中心化節點是一個集羣，也只不過是一個大的單點。

4．  副本數據同步常見問題，1）網絡異常，致使副本沒有獲得數據；2）數據髒讀，主節點數據已經更新，可是因爲某種緣由，沒有獲得最新數據；3）增長新節點沒有獲得主節點數據，而讀數據時重新節點讀數據致使，沒有獲得數據。

5．  去中心化副本控制協議沒有中心節點，協議中全部的節點都是徹底對等的，節點之間經過平等協商達到一致。從而去中心化協議沒有由於中心化節點異常而帶來的停服務等問題。然而，沒有什麼事情是完美的，去中心化協議的最大的缺點是協議過程一般比較複雜。尤爲當去中心化協議須要實現強一致性時，協議流程變得複雜且不容易理解。因爲流程的複雜，去中心化協議的效率和性能較低。

6．  Paxos是惟一在工程中獲得應用的強一致性去中心化副本控制協議。ZooKeeper、Chubby，就是該協議的應用。

Zookeeper用Paxos協議選擇Leader，用Lease協議控制數據是否有效。用Quorum協議把Leader的數據同步到follow。

Zeekeeper，實現Quorum寫入時，若是沒有徹底寫入成功，則全部的follow機器，反向向Leader寫數據，寫入數據後follow又向Leader同步數據，保持一致，若是是失敗的數據先寫入，大家follow同步到原來的數據，相對於回滾；如是是最新的數據先寫入Leader則就是完成了最新數據的更新。

 

7．  Megastore，使用的是改進型行Paxos協議。

8． Dynamo / Cassandra使用基於一致性哈希的去中心化協議。Dynamo使用Quorum機制來管理副本。

9．  Lease機制是最重要的分佈式協議，普遍應用於各類實際的分佈式系統中。1）Lease一般定義爲：頒發者在必定期限內給予持有者必定權利的協議。2）Lease 表達了頒發者在必定期限內的承諾，只要未過時頒發者必須嚴格遵照 lease 約定的承諾；3）Lease 的持有者在期限內使用頒發者的承諾，但 lease 一旦過時必須放棄使用或者從新和頒發者續約。4）的影響。中心服務器發出的lease的含義爲：在lease的有效期內，中心服務器保證不會修改對應數據的值。5）能夠經過版本號、過多上時間、或者到某個固定時間點認爲Lease證書失效。

        其原理和咱們的Cache同樣，好比瀏覽器緩存道理一致。其要求時間時鐘同步，由於數據徹底依賴於期限。

10．              心跳（heartbeat）檢測不可靠,假如檢測及其Q，被檢測機器A，可能因爲Q發起檢測，可是A的迴應被阻塞，致使Q       認爲A宕機，阻塞很快恢復，致使根據心跳檢測來作判斷不可靠；也多是他們之間的網絡斷開；也多是Q機器自己異常致使認爲A機器宕機；若是根據Q的檢測結果，來判斷極可能出現多個主機的狀況。

11．              Write-all-read-one（簡稱WARO）是一種最簡單的副本控制規則，顧名思義即在更新時寫全部的副本，只有在全部的副本上更新成功，才認爲更新成功，從而保證全部的副本一致，這樣在讀取數據時能夠讀任一副本上的數據。寫多份，讀從其中一份讀取。

12．              quorum協議，其實就是讀取成功的副本數大於失敗的副本數，大家讀取的副本里面必定包含了最新的副本。

13．              Mola*和Armor*系統中全部的副本管理都是基於Quorum，即數據在多數副本上更新成功則認爲成功。

14．              Big Pipe*中的副本管理也是採用了WARO機制。

 

 

4、日誌技術

1．  日誌技術是宕機恢復的主要技術之一。日誌技術最初使用在數據庫系統中。嚴格來講日誌技術不是一種分佈式系統的技術，但在分佈式系統的實踐中，卻普遍使用了日誌技術作宕機恢復，甚至如BigTable等系統將日誌保存到一個分佈式系統中進一步加強了系統容錯能力。

2．  兩種比較實用的日誌技術Redo Log與No Redo/No undo Log。

3．  數據庫的日誌主要分爲Undo Log、Redo Log、Redo/Undo Log與No Redo/No Undo Log。這四類日誌的區別在更新日誌文件和數據文件的時間點要求不一樣，從而形成性能和效率也不相同。

4．  本節介紹另外一種特殊的日誌技術「No Undo/No Redo log」，這種技術也稱之爲「0/1目錄」(0/1 directory)。還有一個主記錄，記錄當前工做目錄，好比老數據在0目錄下，新數據在1目錄下，咱們訪問數據時，經過主紀錄，記錄當前是工做在那個目錄下，若是是工做在目錄0下，取目錄0數據，反之取1目錄數據。

5．  MySQL的主從庫設計也是基於日誌。從庫只需經過回放主庫的日誌，就能夠實現與主庫的同步。因爲從庫同步的速度與主庫更新的速度沒有強約束，這種方式只能實現最終一致性。

6．  在單機上，事務靠日誌技術或MVCC等技術實現。

7．  兩階段提交的思路比較簡單，在第一階段，協調者詢問全部的參與者是否能夠提交事務（請參與者投票），全部參與者向協調者投票。在第二階段，協調者根據全部參與者的投票結果作出是否事務能夠全局提交的決定，並通知全部的參與者執行該決定。在一個兩階段提交流程中，參與者不能改變本身的投票結果。兩階段提交協議的能夠全局提交的前提是全部的參與者都贊成提交事務，只要有一個參與者投票選擇放棄(abort)事務，則事務必須被放棄。能夠這麼認爲，兩階段提交協議對於這種超時的相關異常也沒有很好的容錯機制，整個流程只能阻塞在這裏，且對於參與者而言流程狀態處於未知，參與者即不能提交本地節點上的事務，也不能放棄本地節點事務。

8．  第1、兩階段提交協議的容錯能力較差。

9．  第2、兩階段提交協議的性能較差。一次成功的兩階段提交協議流程中，協調者與每一個參與者之間至少須要兩輪交互4個消息「prepare」、「vote-commit」、「global-commit」、「確認global-commit」。過多的交互次數會下降性能。另外一方面，協調者須要等待全部的參與者的投票結果，一旦存在較慢的參與者，會影響全局流程執行速度。

10．              顧名思義，MVCC即多個不一樣版本的數據實現併發控制的技術，其基本思想是爲每次事務生成一個新版本的數據，在讀數據時選擇不一樣版本的數據便可以實現對事務結果的完整性讀取。在使用MVCC時，每一個事務都是基於一個已生效的基礎版本進行更新，事務能夠並行進行。其思想是根據版本號，在多個節點取同一個版本號的數據。

11．              MVCC的流程過程很是相似於SVN等版本控制系統的流程，或者說SVN等版本控制系統就是使用的MVCC思想。

5、CAP理論

14 CAP理論的定義很簡單，CAP三個字母分別表明了分佈式系統中三個相互矛盾的屬性：1）Consistency (一致性)：CAP理論中的副本一致性特指強一致性（1.3.4 ）；

2）Availiablity(可用性)：指系統在出現異常時已經能夠提供服務；

3）Toleranceto the partition of network (分區容忍)：指系統能夠對網絡分區，這

   種異常狀況進行容錯處理。

      2.CAP理論指出：沒法設計一種分佈式協議，使得同時徹底具有CAP三個屬性，即1)該種協議下的副本始終是強一致性，2)服務始終是可用的，3)協議能夠容忍任何網絡分區異常；分佈式系統協議只能在CAP這三者間全部折中。