書名：分散式系統：概念與設計
作者：George Coulouris / Jean Dollimore / Tim Kindberg / Gordon Blair
ISBN：9787111403920

第一章 分散式系統特徵

1. 分散式系統構建原因

主要動力來自於對資源共享的期望，共享資源可以是硬體元件如硬碟，印表機，CPU，也可以是軟體概念如檔案，資料庫，資料物件等。

2. 分散式系統定義和特徵

分散式系統被定義為這樣的一個系統：其硬體或軟體分佈在聯網的計算機上，元件之間通過傳遞訊息進行通訊和動作的協調。通常具備如下顯著特徵：

1. 併發：系統中的多個元件可能同時訪問某一個共享資源
2. 缺乏全域性時鐘：由於時鐘的物理限制及網路的不確定性，元件無法同時獲得一個正確的全域性時鐘
3. 故障獨立性：系統中有多個元件且每個元件都可能單獨出現故障

3. 分散式系統舉例

網際網路和全球資訊網，Web 搜尋，線上遊戲，電子郵件，電子商務，網路會議

4. 分散式系統面臨的挑戰

異構性、開放性、安全性（包括資訊資源的機密性、完整性、可用性）、可伸縮性、故障處理、併發性、透明性、服務質量

第二章 系統模型

1. 分散式系統物理模型

• 基線物理模型：由一組可擴充套件的計算機節點組成，通過網路傳遞訊息，是分散式系統最小物理模型。
• 早期分散式系統：擴充套件自基線模型，基於區域網互連的數十個節點，支援有限的連線並提供少量服務，如共享本地印表機。
• 網際網路規模的分散式系統：擴充套件自基線模型，通過網際網路連線的可擴充套件節點集合，為全球提供分散式服務，如Google搜尋。
• 當代分散式系統：擴充套件自基線模型，異構性大大增加，主要有：
  • 移動計算：裝置的物理位置可以移動，但服務持續可用
  • 無處不在計算：計算節點不再只是桌上型電腦，還增加了大量嵌入式裝置
  • 雲端計算：從“自治節點各自完成給定任務”轉向“一組節點一同提供特定的服務”

2. 分散式系統體系結構模型

2.1. C/S，P2P 兩種結構

C/S 即客戶伺服器模式，分散式系統中最常用的體系結構，在這種體系結構中，客戶可以與不同的伺服器進行互動，而一臺伺服器（的程序）既可以是真實客戶的伺服器，也可以扮演其它伺服器的客戶。

P2P 即對等體系結構，在這種體系結構中，涉及一項任務的所有程序作為對等方扮演相同的角色，實踐中通常所有參與程序執行相同的程式並提供相同的介面（如應用層的多叢集部署）。

2.2. 分層模型，層次化模型

分層指將複雜系統垂直分為若干層，每層利用下層服務而不關心其細節（如 OSI 七層模型），分層模型在分散式系統中就是將較大的服務垂直組織成多個服務層。

層次化模型指的是組織給定層功能的技術，可以理解為同一層服務的水平拆分（比如組織應用層時，將使用者檢視、應用邏輯、資料管理分離）。

3. 互動，故障，安全三種基礎模型

互動模型：考慮影響互動的兩個主要因素（通訊效能和計算機時鐘），有兩種不同的設計，分別是同步分散式系統和非同步分散式系統。前者規定：程序執行每一步的時間都有上限和下限，通過通訊通道傳遞的每個訊息在已知的時間範圍內收到，每個程序都有本地時鐘，它的時鐘漂移率在一個可控範圍內；後者規定：對程序的執行速度沒有限制，訊息傳遞延遲可以任意長，時鐘漂移率可以是任意的（網際網路的設計就是基於非同步分散式系統）。

故障模型：定義了故障可能發生的方式，分為遺漏故障（程序或通訊通道不能完成它應該完成的動作，如程序崩潰、訊息緩衝區溢位）、隨機故障或拜占庭故障（可能出現的最壞故障，如響應錯誤的值、訊息損壞）、時序故障（只適用於同步分散式系統，如程序執行超時，訊息超時或者時鐘漂移率超限）。

安全模型：用於描述在開放的分散式系統中，對程序和通訊通道可能的威脅及保護措施。如伺服器收到假冒的客戶請求，客戶收到被篡改的伺服器響應，分散式拒絕服務攻擊，通訊通道監聽等。密碼學、安全通道可以用於防範這些問題。

4. 同步，非同步兩種不同分散式系統

同步分散式系統中規定，程序執行每一步的時間都有上限和下限，通過通訊通道傳遞的每個訊息在已知的時間範圍內收到，每個程序都有本地時鐘，它的時鐘漂移率在一個可控範圍內。

非同步分散式系統中規定，程序的執行速度沒有限制，訊息傳遞延遲可以任意長，時鐘漂移率可以是任意的（網際網路的設計就是基於非同步分散式系統）。

第三章 時間和全域性狀態

1. 事件，程序歷史概念

事件：發生了一個動作（通訊或狀態轉換），該動作由一個程序完成。

程序歷史：在該程序中發生過的一系列事件，且按照發生在先關係排序（類似時間線）。

2. 時鐘漂移及產生原因

時鐘漂移指兩個時鐘的讀數間的瞬時不同（理解為每一個時鐘 “1s” 都不完全一樣長），因為時鐘的實現基於晶體振盪頻率，而兩個不同振盪器的頻率不可能完全一致，甚至溫度變化也會引起頻率變化，所以會產生時鐘漂移。儘管這個差異很小，但長期累積起來仍會產生可感知的時間差異。

3. 內部、外部物理時鐘同步

內部同步：指如果兩個時鐘同步到了已知精度，那麼我們可以通過本地時間度量在不同計算機上發生的兩個事件的時間間隔，即使它們沒有與外部時間源同步。

外部同步：指使用權威的外部時間源對本地時鐘進行同步。

4. 物理時鐘正確性

通常，如果一個硬體時鐘的漂移率在一個已知的範圍內（該範圍通常由製造商提供），那麼該時鐘就是正確的，這保證了時間誤差是有界的。

5. 物理時鐘同步的三種方法

Cristian 方法：使用一個時間伺服器，它連線接收 UTC 訊號的裝置，用於外部同步。之後，其它主機（程序）向伺服器傳送“請求時間”訊息並記錄傳送時間 \(t_{mr}\)，伺服器返回自己的時間 \(t\)，再根據返回訊息的到達時間 \(t_{mt}\) 估計往返時間 \(t_{round}\)，其中 \(t_{round} = t_{mt} - t_{mr}\)，即可估計自己應該設定的值 \(T \approx t + (t_{round} / 2)\)。
儘管可以通過多傳送幾個請求減少誤差，但此方法仍然不一定足夠可靠，因為這依賴於（無法保證的）往返時間誤差與所要求的精確度相比足夠小，或者單個時鐘伺服器故障導致整個系統無法進行時鐘同步，因此主要用於內部網路。

Berkeley 方法：不需要外部精確時間源，僅用於內部同步。選擇一臺協調者計算機作為主機，主機定期輪詢其它從屬機，從屬機將它們的時鐘返回給主機，主機觀察往返時間來估計從屬機的本地時鐘，並計算應調整值（正或負）的平均值。
此方法使用了類似 Cristian 方法估計往返時間的策略，因此也會存在一定誤差。且主機故障後要選取另一臺主機接管，但該方法沒有保證選舉在有限時間內完成。

網路時間協議（NTP）：定義了時間服務的體系結構和在網際網路釋出時間資訊的協議，是如今網際網路裝置廣泛使用的時鐘同步協議。該協議的設計目標：

• 提供一個服務，使得跨網際網路的使用者可以和 UTC 進行（可接受誤差範圍內的）精確同步，依賴於過濾時序資料的統計技術
• 提供可靠服務，依賴於冗餘伺服器並在伺服器之間設定冗餘路徑
• 可以經常進行同步，以抵消大多數裝置的時鐘漂移，且能擴充套件到處理大量客戶和伺服器場景
• 提供對時間伺服器的保護，使用認證技術檢查時序資料

6. 邏輯時鐘

Lamport 發明的一種簡單機制，可以數字化發生在先排序。它規定每個程序維護自己的邏輯時鐘（一個單調增長的計數器），程序 \(p_i\) 用它給事件加上 Lamport 時間戳 \(L_i\)。若程序觸發了某個事件，則將該事件標註時間戳為 \((L_i + 1)\)；傳送訊息時，在訊息中附帶 \(t = L_i\)；接收程序接收訊息事件被標註時間戳為 \(max(L_j, t)\)。

7. 發生在先關係、併發關係及分散式系統中的事件排序

發生在先關係/因果序/潛在的因果序

1. 若對於程序 \(p_i\) 內的兩個事件 \(e \rightarrow_i e^{'}\)，則有事件順序 \(e \rightarrow e^{'}\)，表示 \(e\) 在 \(e^{'}\) 之前發生
2. 對於任意訊息 \(m\)，均有 \(send(m) \rightarrow receive(m)\)
3. 滿足傳遞性，\(e \rightarrow e^{'}, e^{'} \rightarrow e^{''} \Rightarrow e \rightarrow e^{''}\)

基於以上規則，若對於事件 \(e, e^{'}\) 組成的偏序滿足以上條件，則稱它們是發生在先關係，記作 \(e \rightarrow r^{'}\)

併發關係
兩個事件不能由發生在先關係進行排序，一般發生在不同程序中且沒有因果關係，記作 \(a || b\)

事件排序
有因果關係的事件順序可以由發生在先關係描述，但發生在先關係並不一定表示兩個事件有先後順序，如併發關係

8. Lamport 邏輯時鐘、全序邏輯時鐘及向量時鐘

Lamport 時鐘：Lamport 發明的一種簡單機制，可以數字化發生在先排序。它規定每個程序維護自己的邏輯時鐘（一個單調增長的計數器），程序 \(p_i\) 用它給事件加上 Lamport 時間戳 \(L_i\)。若程序觸發了某個事件，則將該事件標註時間戳為 \((L_i + 1)\)；傳送訊息時，在訊息中附帶 \(t = L_i\)；接收程序接收訊息事件被標註時間戳為 \(max(L_j, t)\)。

全序邏輯時鐘：全域性邏輯時間戳定義為 （Lamport 時間戳，程序識別符號）並規定 $T_i \le T_j, i \le j \ \iff \ (T_i, i) < (T_j, j) $，儘管程序識別符號的比較一般沒有實際意義，但在諸如臨界區排序（同時請求時按程序識別符號從小到大進入）時還是可以實現相關功能的。

向量時鐘：向量時鐘用於克服 Lamport 時鐘的缺陷（併發關係場景下，儘管 \(L_i < L_j\) 但無法推出 \(e_i \rightarrow e_j\)）。假設系統中有 N 個程序，則向量時鐘定義為一個 N 維整數向量，每個程序維護一個自己的向量時鐘

9. 割集、割集的一致性、一致的全域性狀態概念

割集：分散式系統所有程序全域性歷史的子集，是程序歷史字首的並集

割集的一致性：割集 C 是一致的，即對於任意事件 \(e \in C, f \rightarrow e \iff f \in C\)，即有果必有因

一致的全域性狀態：對應於一致割集（增量序列）的狀態 S0 -> S1 -> S2 -> …（系統的執行可以描述成系統全域性狀態之間的一系列轉換）

10. Chandy-Lamport 快照演算法（Spark、Flink 都有類似實現）

演算法目的是記錄所有程序的程序狀態和通道狀態，所記錄的程序狀態組合可能不完全切合實際的時間點（可能程序 \(p_i, p_j\) 記錄的最後事件分別是 \(a, b\)，但實際兩個事件並不是發生在同一時間），但一定是一致的（中間沒有事件缺失）。演算法有如下假設

1. 不論是通道還是程序都不會出現故障，通訊是可靠的，每個發出的訊息最終會被完整接收一次
2. 通道是單向的，提供 FIFO 的訊息傳遞
3. 進所有程組成的圖是強連通的，即任意兩個程序之間都有通道（接收通道、外發通道）
4. 任一程序都可在任一時間發起全域性快照
5. 快照時，程序可以繼續執行或者傳送接收訊息

演算法定義了兩個規則：標記傳送規則和標記接收規則。前者強制記錄下自己狀態的程序立即傳送一個標記資訊，後者強制沒有記錄狀態的程序去記錄自己的狀態。任何程序都可以在任何時間開始這個演算法，下圖是兩個規則的虛擬碼：

第四章 協調和協定

1. 分散式互斥的含義

分散式程序常常需要協調它們的動作，如訪問共享資源時需要互斥來防止干擾並保證一致性，這對應作業系統領域常見的“臨界區”問題。然而分散式系統中原有互斥方法基本均失效，需要一個僅基於訊息傳遞的分散式互斥解決方案。基本要求如下：

1. ME1. 安全性（互斥）：在臨界區一次最多有一個程序執行
2. ME2. 活性（有限等待）：進入和離開臨界區的請求最終將成功執行
3. ME3. 發生在先順序（happen-before）：先請求進入臨界區的程序先進入臨界區

常用評價標準：

1. 頻寬：消耗的頻寬，與進入和退出臨界區傳送訊息的數量成正比
2. 延遲：每次進入和退出操作導致的客戶延遲
3. 吞吐量：用一個程序離開臨界區和下一個程序進入臨界區之間的同步延遲來衡量

2. 解決分散式互斥的方法：中央伺服器、令牌環、組播+邏輯時鐘、Maekawa 投票演算法

中央伺服器：使用一箇中央伺服器進行臨界區進入授權，要進入臨界區的程序向該伺服器傳送訊息並等待應答。滿足 ME1，ME2，不滿足 ME3，缺點是伺服器可能會成為整個系統的效能瓶頸

令牌環：將所有程序安排在一個邏輯環上，通過獲取在程序間沿著環單向傳遞的令牌（訊息），來實現互斥。環的拓撲結構可以和計算機物理位置無關。滿足 ME1，ME2，不滿足 ME3，該演算法可能會消耗更多的網路頻寬。

組播+邏輯時鐘：要進入臨界區的程序組播一個訊息，只有在其他程序都應答了這個訊息後才能進入，如果訊息接收程序沒有進入臨界區，或者想要進入臨界區但向量時鐘較大（後發生），則馬上給出應答訊息，否則入隊該訊息且暫時不給出應答訊息。程序退出臨界區時，對佇列中未應答的訊息給出應答。滿足 ME1，ME2，ME3。

Maekawa 投票演算法：每個程序關聯一個選舉集，每個選舉集有相同數量程序，任意兩個選舉集之間有交集（同一個程序）防止同時當選，程序進入臨界區需要獲得足夠的選票。大概過程：程序傳送請求進入臨界區訊息給自己選舉集中的所有程序，包括自己，在收到所有應答之前，不能進入臨界區。選舉集中的程序只要不是自己在臨界區中，或者已經給別人投了票，就應該立即傳送應答訊息，否則入隊訊息暫時不給出應答。此方法滿足 ME1，但是易死鎖，改進版中，程序按照發生在先順序應答佇列中的請求，無死鎖且滿足 ME3。

3. 分散式選舉含義

選擇唯一的一個程序來扮演特定角色的演算法稱為選舉演算法。

4. 解決分散式選舉的方法：環、霸道演算法

基於環
將程序組織為邏輯環，只有相鄰程序間可以單向通訊（如順時針）通訊。最初每個程序都是非參與者，任何程序均可開始一次選舉，將自己標記為參與者，順時針傳送選舉訊息給鄰居。選舉流程如下：

1. 如果到達的識別符號較小，自己又不是參與者，則將識別符號替換為自己的（晉級參與者）並向後轉發訊息；如果已經是參與者，則不修改該訊息並原樣傳遞。
2. 如果收到的選舉訊息中，識別符號是自己的，則當選為協調者，將自己標記為非參與者並轉發當選訊息（選舉結束）

最壞情況下，共需要 (N - 1) + N + N 個訊息完成選舉，即（傳遞選舉訊息到最大節點 + 包含最大節點的選舉訊息被沿環傳遞迴該節點 + 沿著環傳遞一週的當選訊息）。

霸道演算法
假定每個程序都知道哪些程序有更大的識別符號，且可以和所有這些程序通訊。訊息型別分為：Election、Answer/alive、Coordinator/victory。當程序監測到 leader 失聯或者某個程序從故障中恢復時會發起選舉，選舉流程如下：

1. 程序 \(p\) 的識別符號是最大的，直接向所有程序傳送 victory 訊息
2. 程序 \(p\) 的識別符號不是最大，且 leader 失聯，向所有比自己大的程序傳送 election 訊息。如果收到 alive 訊息則停止傳送 election，等待 victory 訊息。一段時間等不到重新開始選舉
3. 程序收到了比自己小的程序發來的 election，回覆一個 alive，重新開始選舉流程
4. 程序收到 victory 訊息，則將傳送者標記為 leader

5. 組通訊的協調與協定

5.1 基本組播、可靠組播的區別

組播/組通訊
如何將一條訊息在兼顧可靠性和某種順序策略的基礎上，保證傳遞給組內所有成員

基本組播

1. 定義基本組播原語 B-Multicast，用於應用層（組播程序）呼叫協議層（組播協議）實現基本組播；其簡單實現方案可以讓協議層向組成員傳送一對一的 send 請求
2. 定義基本交付原語 B-Deliver，用於協議層嚮應用層（組播接收程序）交付組播訊息；對於網路層 receive 到組播訊息的程序，通過呼叫該原語交付給應用層
3. 一種提高發送效率的方法，使用多執行緒併發執行 send 操作，但這可能會帶來確認爆炸，緩衝區被迅速填滿並增加訊息丟棄的可能性
4. 最終實現目的：只要組播程序不崩潰，一個正確的接收程序終將交付該訊息給應用層

可靠組播

1. 完整性（integrity）：一個正確（沒有故障）的程序 Deliver 一個訊息至多一次
2. 有效性（validity）：如果一個正確的程序 Multicast 了某個訊息，那麼它自己終將會 Deliver 該訊息給自己
3. 協定（agreement）：如果一個正確的程序 Deliver 了某個訊息，那麼該組中的其它正確程序終將 Deliver 該訊息

其中有效性和協定共同保證了整個系統的 liveness：如果某個正確的程序 Multicast 了某個訊息，那麼目標組內的所有正確程序都終將 Deliver 該訊息。

5.2 實現可靠組播的方法

協定表明了 B-Multicast 不能再基於一對一的 send 來實現，因為組播程序在 send 中途出現故障時，會導致剩餘程序無法 Deliver 該訊息。可行方案如下：

1. 基於 B-Multicast 實現可靠組播：核心思想是讓所有接收程序在 Deliver 之前執行一次 Multicast，即每一個正確接收的程序都作為組播程序的中繼。這樣即使組播程序中途故障，也會有正確接收的程序發出 Multicast 給剩餘程序。缺點是效率低下，同組內 N 個程序都要接收同一個組播訊息 N 次。且系統中的所有程序都要實現對重複訊息的過濾
2. 基於 IP 組播實現可靠組播：將 IP組播、捎帶確認法、否定確認結合起來，實現可靠的 Multicast 和 Deliver

6. 共識、互動一致性及拜占庭將軍問題含義

這三類問題統稱為協定，即在一個或多個程序提議了一個值應當是什麼後，使系統內所有程序對這個值達成一致的意見。

7. 三個、四個拜占庭將軍問題

三將軍問題
假設有三個獨立的拜占庭將軍 A，B，C，他們之間只通過信使進行通訊，現在他們需要協商一個問題：明天要進攻還是撤退。這種情況下，為達成一致只需要使用少數服從多數原則，即只要兩個人意見相同即可。但不幸的是，三人當中可能會出現叛徒，考慮如下情況，A、B 做出了相反的決策，此時 C 分別向 A、B 發出不同的決策，這就會導致 A、B 採取不一致行動，從而導致失敗。可以證明三將軍問題是無解的，即無法找出三人之中的叛徒。

四將軍問題
四將軍問題與三將軍問題類似，但不同之處在於，四將軍問題存在可行的解決演算法。

拜占庭將軍問題，本質上是在描述分散式系統中可能出現最壞情況的一個故障模型：由於系統中存在拜占庭故障（不響應、回覆錯誤訊息、回覆不一致訊息等）的節點，導致系統出現了不一致狀態或行為，而且這個不一致無法感知到。如果存在一個演算法能夠使得系統在出現拜占庭故障時仍能保持一致性，那麼這個演算法基本上可以應用在各種場景下系統一致性的保證。因為沒有比拜占庭故障更離譜的故障了。

但在實際應用中，並不一定需要如此苛刻的模型，因為系統中大多數的節點不太可能像拜占庭將軍一樣有主觀惡意，除非節點已經感染了病毒，一般情況下能避免伺服器宕機這類錯誤導致的不一致就可以了。

8. Paxos 演算法

Paxos 演算法將系統中的節點分為三種不同的角色（類比場景為國會議案投票）：

1. Proposer：提議者，向叢集提出某個提議
2. Acceptor/Voter：投票者，對提議者的提議進行投票，只有形成法定人數（一般是多數派）時提議才會被接受
3. Learner：接受者，對任意被接受的提案都同意（混子）

演算法分為兩大四小階段：

• 提案和投票
  • Prepare：Proposer 提出一個 N 號提案，並請求 Acceptors 接受此提案
  • Promise：Acceptor 迴應 Proposer 的提案，只要 Acceptor 之前收到的提案號都比 N 小，則返回接受；否則拒絕該提案
• 確認和通過
  • Accept：Proposer 收到了足夠多的 Acceptor 的接受迴應，則向 Acceptor 發起 Accept 請求，包含提案號和內容
  • Accepted：Acceptor 在此期間沒有收到更大的提案，則返回 Accepted 表示該提案通過，否則忽略。若通過則把通過的提案發給 Learner

Basic Paxos 存在活鎖問題（儘管系統沒有被真正阻塞，但因為某些條件不滿足使得程序一直在重複執行“嘗試-失敗”，而無法繼續向下執行任何有實際業務意義的程式碼），比如兩個或多個 Proposer 在提案和投票階段相互競爭，導致長期都不能通過任何提案。解決方法是使用 Random Timeout 策略，讓衝突的 Proposer 等待一段隨機時間，減少衝突的可能。

9. Raft 演算法（動畫演示）

Raft 演算法將系統中的節點分為三種不同的角色：

1. Follower：預設節點狀態
2. Candidate：參選者，即參與競選 Leader 的節點，會從 Follower 切換為 Candidate
3. Leader：競選成功的節點，會從 Candidate 切換為 Leader

系統中的主要流程如下：

1. Leader 會定時（Heartbeat Timeout）向 Follower 傳送心跳（Heartbeat），每個 Follower 都維護一個 Random Timeout，每收到一次心跳則重置超時倒計時（Election Timeout）
2. Leader Election：任一 Follower 隨機一段時間後（Election Timeout，150ms ~ 300ms）沒收到心跳則可晉級 Candidate 並啟動新的選舉，得到多數 Follower 同意的 Candidate 即可當選 Leader，此時任期遞增（Term+1）。如果多個 Candidate 同時啟動選舉，則會等待隨機時間重新開始。
3. Log Replication：客戶端發起的變更操作均請求到 Leader，生成一個 Log Entry 並複製到所有 Follower，完成後 Leader 響應客戶端。這樣系統狀態是一致的
4. 網路分割槽時，系統會出現多個 Leader，當網路分割槽修復後，任期小的 Leader 會自動下臺，小任期下的 Follower 均會回滾自己的 Log Entry 並和有效 Leader 保持一致

第五章 事務和併發控制 & 分散式事務

1. 序列等價性的概念、充要條件及應用

序列等價性：如果併發事務交錯執行的結果，一定和某種依次序列執行每個事務的結果相同，就稱這是一種序列等價的交錯執行

序列等價性充要條件：兩個事務中所有的衝突操作，都按照相同的次序在它們訪問的物件上執行

序列等價性應用：可作為一個標準用於生成併發控制協議

2. 事務的三種基本控制方法：鎖、樂觀方法、時間戳，它們的原理、實現、比較

2PL
兩階段加鎖，最簡單的併發控制，考慮的問題是如果併發控制不事先將所有需要的鎖申請好，而是釋放鎖後還允許再次申請，很有可能導致事務之間出現死鎖（2PL 類似死鎖預防中的破壞請求並保持條件）。而且如果同一事務內兩次操作同一物件之間，其它事務修改了這個資料物件，進而導致不可重複讀（同一事務內兩次讀取到不一致的資料）或丟失更新問題。

S2PL
嚴格的兩階段加鎖，規定寫鎖要在事務提交或放棄時才可以釋放。因為 2PL 下可能出現髒讀或級聯放棄問題，S2PL 作了進一步的嚴格限制，避免了這些問題。

OCC
樂觀併發控制

MVCC
多版本併發控制

CMU 將併發控制方式分為兩種，一種是基於 2PL 的，悲觀鎖相關的都可規納入此類；一種是基於時間戳排序的，OCC 和 MVCC 都屬於這種。

第六章 複製

1. 複製的概念、動機、基本要求

複製的概念：在多個計算機中進行資料副本的維護

複製的動機：是保證分散式系統有效性的關鍵技術之一，可用於增強效能，提供高可用性和容錯能力

複製的基本要求：

1. 透明性：客戶不知道也不需要知道多個物理副本的存在，以及它們之間的組織方式，客戶只需要知道有一個完整的邏輯資料物件即可。
2. 一致性：針對一個 “複製的資料物件” 的操作，是否能得到滿足這個物件正確性要求的結果。比如多人編輯的協作文件，不同使用者應當看到同樣的內容，如果看到不一致的內容通常是不可接受的。

2. 複製的系統模型: 主動複製、被動複製

3. 單拷貝序列化的概念、“讀一個/寫所有”方案原理、適用條件及本地驗證方法

3. Gossip 系統的兩個保證、體系結構（含關鍵資料結構）及基本操作

4. Coda 體系結構及複製策略

第七章 分散式檔案系統

1. 分散式檔案系統的需求

2. 檔案服務體系結構，即三個元件、作用、介面，設計理念

3. NFS 體系結構、NFS伺服器操作、路徑解析、快取機制

4. AFS 應用場景、設計理念、快取機制、一致性

第八章 GFS（Google File System）

1. GFS 設計動機、設計思想、體系結構

設計動機及思想：為了滿足 Google 迅速增長的資料處理需求，設計並實現了 GFS。GFS 與傳統的分散式檔案系統有著很多相同的設計目標，比如，效能、可伸縮性、可靠性以及高可用性。但是，其設計還受到 Google 應用的負載情況和技術環境的影響，與早期檔案系統的假設都有明顯的不同：

1. 元件失效（系統故障）是常態而非意外事件
2. 通常情況下，系統所需處理的檔案都是大檔案而非類似 AFS（安卓檔案系統）那樣的小檔案
3. 絕大部分對檔案的修改操作，都是追加寫，很少有隨機寫
4. 檔案系統 API 和應用程式協同設計，使得整個系統更靈活（GFS 有一些 “專用性”）

系統角色：

1. Master：單節點，管理檔案系統元資料以及變更日誌，不儲存原始檔案，而元資料通常並不大
2. Chunk Server：多節點，對 Chunk（檔案塊）進行物理儲存，響應 Client 的操作（讀取、寫入、刪除等）
3. Client：GFS 的使用者，通常多節點，會向 Master 和 Chunk Server 發出檔案操作請求

2. Master 不存在效能瓶頸原因

儘管為了簡化系統設計選擇了單 Master 節點，但採取了一系列措施減少 Master 的壓力，避免成為瓶頸：

1. 客戶端不通過 Master 讀寫檔案資料，即只有控制流經過 Master，資料流不經過 Master
2. GFS Client 可以本地快取部分元資料而無需與 Master 互動
3. 通過使用大尺寸 Chunk，壓縮元資料等，提高了 Master 記憶體利用率

3. 讀、寫、追加操作流程

讀操作流程：

1. 應用程式發出讀請求給 GFS Client 程式
2. 客戶端將請求轉換為（檔名、塊索引），發給主伺服器
3. 主伺服器返回資料塊的控制代碼和副本位置資訊，即 Chunk Server 的位置
4. Client 選擇其中一個 Chunk Server，並給那個塊伺服器傳送請求
5. 塊伺服器返回請求的資料
6. Client 將資料傳送給應用程式

寫操作流程：

1. GFS 客戶端傳送請求到主伺服器
2. 主伺服器返回塊的控制代碼和副本的位置資訊
3. 客戶端將寫資料傳送給所有副本伺服器
4. 資料儲存在副本伺服器的快取中
5. 客戶端傳送寫命令到主副本伺服器
6. 主副本伺服器給出寫的次序
7. 主副本伺服器將該次序傳送給二級副本伺服器
8. 二級副本管理器響應主副本伺服器
9. 主副本伺服器響應客戶端

追加寫操作流程：

1. 應用程式提出新增操作的請求
2. Client 將請求發給主伺服器
3. 主伺服器返回塊控制代碼和副本位置
4. Client 將要寫入的資料推入各個副本
5. 主副本伺服器檢查新增操作是否會導致該塊超過最大的規模
6. 如果超過，將該塊擴充到最大規模，其它副本做同樣的操作，同時通知 Client 該操作需要在下一個塊上重新嘗試
7. 如果不超過，主副本伺服器將資料新增到它的副本上，並告訴其它的副本在同樣的 offset 處追加寫資料，最後主副本伺服器向 Client 報告追加寫成功

4. 寫操作一致、確定含義及分析

第九章 P2P（對等系統）

1. P2P基本結構型別：中心化網路、分散式（結構化、非結構化）、混合式

2. 一致性雜湊演算法

3. 分散式雜湊表主要思想

4. Chord原理、Hash表分佈規則、基於Finger Table的路由技術

Reference

1. 分散式系統中的組播