一、分佈式系統基礎重要要點：
- 對外提供無狀態節點，內部實現具體有狀態或者無狀態節點邏輯，節點即可以是提供服務，也可以是存儲數據。
- 拜占庭問題，在分佈式系統中的使用，目的是保證服務可用，而不是找出錯誤的節點，如果。
- 異常常見情況，機器宕機、網絡異常、消息丟失、消息亂序、數據錯誤、不可靠的TCP。可能是收到消息後宕機、也可能是處理完成以後機器宕機、處理完成任務後發送確認消息是網絡異常。也有可能是發出去的消息丟失，或者發送確認消息時丟失。可能先發送出去的數據後收到
- 分佈式狀態、成功、失敗、超時。超時的情況，不能判斷是否成功，原有同上。
- 數據存儲在機械硬盤上，隨時有可能發生異常，導致數據沒有能正確存儲。
- 無法歸類的異常，比如，系統的處理能力時高、時低，的詭異行為。
- 即使是小概率事件，在每天百萬、千萬、及以上的運算量時也會上升為大概率事件。
- 副本提高數據的冗餘，提高系統的可用性，但是在使用副本代來好處的同時，也導致維護副本需要成本。如副本的一致性，多個副本一致性，多個副本直接可能到不一致。
- 一致性級別：強一致性、單調一致性，讀取最新數據、會話一致性，通過版本讀取統一值。最終一致性、弱一致性。
- 分佈式系統性能指標：吞吐量、響應延遲、併發量；常用單位QPS，即每秒鐘的處理能力。高吞吐量會帶來低響應、他們之間是相互制約關係。
- 可用性指標：可以服務時間和非服務時間的比率和請求的成功和失敗次數來衡量。
- 可擴展性指標：實現能水平擴展，增加低配置的機器即可以實現更大的運算量，和更高的處理能力。
- 一致性指標：實現副本間的一致性能力，一致性需要嚴格考量是否業務允許。
二、分佈式系統原理：
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按哈希方式和按數據量分佈組合。
三、數據副本協議
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機制。
四、日誌技術
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． 第一、兩階段提交協議的容錯能力較差。
9． 第二、兩階段提交協議的性能較差。一次成功的兩階段提交協議流程中，協調者與每個參與者之間至少需要兩輪交互4個消息“prepare”、“vote-commit”、“global-commit”、“確認global-commit”。過多的交互次數會降低性能。另一方面，協調者需要等待所有的參與者的投票結果，一旦存在較慢的參與者，會影響全局流程執行速度。
10． 顧名思義，MVCC即多個不同版本的數據實現併發控制的技術，其基本思想是為每次事務生成一個新版本的數據，在讀數據時選擇不同版本的數據即可以實現對事務結果的完整性讀取。在使用MVCC時，每個事務都是基於一個已生效的基礎版本進行更新，事務可以並行進行。其思想是根據版本號，在多個節點取同一個版本號的數據。
11． MVCC的流程過程非常類似於SVN等版本控制系統的流程，或者說SVN等版本控制系統就是使用的MVCC思想。
五、CAP理論
- CAP理論的定義很簡單，CAP三個字母分別代表了分佈式系統中三個相互矛盾的屬性：1）Consistency (一致性)：CAP理論中的副本一致性特指強一致性（1.3.4 ）；
2）Availiablity(可用性)：指系統在出現異常時已經可以提供服務；
3）Toleranceto the partition of network (分區容忍)：指系統可以對網絡分區，這
種異常情況進行容錯處理。
2.CAP理論指出：無法設計一種分佈式協議，使得同時完全具備CAP三個屬性，即1)該種協議下的副本始終是強一致性，2)服務始終是可用的，3)協議可以容忍任何網絡分區異常；分佈式系統協議只能在CAP這三者間所有折中。
閱讀更多 cpp軟件架構獅 的文章
