1. 分散式系統相關概念

1.1 模型

1.1.1 節點

節點是一個可以獨立按照分散式協議完成一組邏輯的程式個體，工程中往往指程序。

1.1.2 通訊

節點之間完全獨立互相隔離，通訊唯一方式是通過不可靠的網路。

1.1.3 儲存

節點可以通過將資料寫入與節點在同一臺機器的本地儲存裝置儲存資料

1.1.4 異常

(1) 機器down機

大型叢集每日down機發生概率0.1%，後果是該機器節點不能工作、重啟後失去所有記憶體資訊。

(2) 網路異常

• 訊息丟失：網路擁塞、路由變動、裝置異常、network partition（部分不正常）

• 訊息亂序：IP儲存轉發、路由不確定性、網路報文亂序

• 資料錯誤：位元錯誤

• 不可靠TCP：到達協議棧之後與到達程序之間、突然down機、分散式多個節點的tcp亂序

(3) 分散式系統的三態

任何請求都要考慮三種情況：成功、失敗、超時。對於超時的請求，無法獲知該請求是否被成功執行。

(4) 儲存資料丟失

(5) 其他異常

IO操作緩慢、網路抖動、擁塞

1.2 副本

1.2.1 副本的概念

replica/copy 指在分散式系統中為資料或服務提供的冗餘：

• 資料副本：在不同的節點上持久化同一份資料。例如GFS同一個chunk的數個副本

• 服務副本：數個節點提供相同的服務，服務不依賴本地儲存，資料來自其他節點。例如Map Reduce的Job Worker

1.2.2 副本的一致性

副本的consistency是針對分散式系統而言的，不是針對某一個副本而言。根據強弱程度分為：

• 強一致性：任何時刻任何使用者/節點都可以讀到最近一次更新成功的副本資料

• 單調一致性：任何時刻任何使用者一旦讀到某個資料某次更新後的值，就不會再讀到更舊的值

• 會話一致性：任何時刻任何使用者在某次會話內一旦讀到某個資料某次更新後的值，就不會在這次會話再讀到更舊的值

• 最終一致性：各個副本的資料最終將達到一致狀態，但時間不保證

• 弱一致性：沒有實用價值，略。

1.3 衡量分散式系統的指標

1.3.1 效能

• 吞吐量：某一時間可以處理的資料總量

• 響應延遲：完成某一功能需要使用的時間

• 併發能力：QPS(query per second)

1.3.2 可用性

系統停服務的時間與正常服務的時間的比例

1.3.3 可擴充套件性

通過擴充套件叢集機器提高系統性能、儲存容量、計算能力的特性，是分散式系統特有的性質

1.3.4 一致性

副本帶來的一致性問題

2. 分散式系統原理

2.1 資料分佈方式

無論計算還是儲存，問題輸入物件都是資料，如何拆分分散式系統的輸入資料稱為分散式系統的基本問題。

2.1.1 雜湊方式

一種常見的雜湊方式是按照資料屬於的使用者id計算雜湊。

優點：

• 雜湊性：好

• 元資訊：只需要函式+伺服器總量

缺點：

• 可擴充套件性：差。一旦叢集規模擴充套件，大多數資料都需要被遷移並重新分佈

• 資料傾斜：當某個使用者id的資料量異常龐大時，容易達到單臺伺服器處理能力的上限

2.1.2 按資料範圍分佈

將資料按特徵值的值域範圍劃分資料。例如將使用者id的值域分為[1, 33), [33, 90), [90, 100)，由三臺伺服器處理。注意區間大小與區間內的資料大小沒有關係。

優點：

• 可擴充套件性：好。靈活根據資料量拆分原有資料區間

缺點：

• 元資訊：大。容易成為瓶頸。

2.1.3 按資料量分佈

與按範圍分佈資料方式類似，元資訊容易成為瓶頸

2.1.4 一致性雜湊

(1) 以機器為節點

用一個hash函式計算資料（特徵）的hash值，令該hash函式的值域成為一個封閉的環，將節點隨機分佈在環上。每個節點負責處理從自己開始順時針到下一節點的值域上的資料。

優點：

• 可擴充套件性：極好。任意動態新增、刪除節點，隻影響相鄰節點

缺點：

• 元資訊：大而且複雜

• 隨機分佈節點容易造成不均勻

• 動態增加節點後只能緩解相鄰節點

• 一個接點異常時壓力全轉移到相鄰節點

(2) 虛節點

虛節點，虛節點個數遠大於機器個數，將虛節點均勻分佈到值域環上，通過元資料找到真實機器節點。

優點：

• 某一個節點不可用導致多個虛節點不可用，均衡了壓力

• 加入新節點導致增加多個虛節點，緩解了全域性壓力

2.1.5 副本與資料分佈

前邊4中資料分佈方式的討論中沒有考慮資料副本的問題。

(1) 以機器為單位的副本

缺點：

• 恢復效率：低。假如1出問題，從2 3 中全盤拷貝資料較消耗資源，為避免影響服務一般會將2下線專門做拷貝，導致正常工作的副本只有3

• 可擴充套件性：差。假如系統3臺機器互為副本，只增加兩臺機器的情況下無法組成新的副本組。

• 可用性：差。一臺donw機，剩下兩臺壓力增加50%。理想情況會均攤到整個叢集，而不是單個副本組

(2) 以資料段為單位的副本

例如3臺伺服器，10G資料，按100hash取模得到100M每個的資料段，每臺伺服器負責333個數據段。一旦將資料分成資料段，就可以以資料段為單位管理副本，副本與機器不再硬相關。

例如系統中3個數據o p q, 每個資料段有三個副本，系統中有4臺機器：

優點：

• 恢復效率：高。可以整個叢集同時拷貝

• 可用性：好。機器donw機的壓力分散到整個叢集

工程中完全按照資料段建立副本會引起元資料開銷增大，這種做法是將資料段組成一個大資料段。

2.1.6 本地化計算

如果計算節點和儲存節點位於不同的物理機器，開銷很大，網路頻寬會成為系統的瓶頸；將計算排程到與儲存節點在同一臺物理機器上的節點計算，稱為計算本地化。

2.2 基本副本協議

2.2.1 中心化副本控制協議

• 中心化副本控制協議的基本思路：由一箇中心節點協調副本資料的更新、維護副本之間一致性，併發控制

• 併發控制：多個節點同時需要修改副本資料時，需要解決的“寫寫”、“讀寫”等併發衝突

單機系統使用加鎖等方式進行併發控制，中心化協議也可以使用。缺點是過分依賴中心節點。

2.2.2 primary-secondary協議

這是一種常用的中心化副本控制協議，有且僅有一個節點作為primary副本。有4個問題需要解決：

(1) 資料更新基本流程

• 由primary協調完成更新

• 外部節點將更新操作發給primary節點

• primary節點進行併發控制並確定併發更新操作的先後順序

• primary節點將更新操作傳送給secondary節點

• primary根據secondary節點的完成情況決定更新是否成功，然後將結果返回外部節點

其中第4步，有些系統如GFS使用接力的方式同步資料，primary -> secondary1 ->secondary2，避免primary的頻寬稱為瓶頸。

(2) 資料讀取方式

• 方法一：由於資料更新流程都是由primary控制的，primary副本上資料一定最新。所以永遠只讀primary副本的資料能夠實現強一致性。為了避免機器浪費，可以使用之前討論的方法，將資料分段，將資料段作為副本單位。達到每臺機器都有primary副本的目的。

• 方法二：由primary控制secondary的可用性。當primary更新某個secondary不成功時，將其標記為不可用。不可用的secondary副本繼續嘗試與primary同步資料，直到成功同步後轉為可用狀態。

• 方法三：Quorum機制。後續討論。

(3) primary副本的確定與切換

• 如何確定primary副本？primary副本所在機器異常時，如何切換副本？

• 通常在primary-secondary分散式系統中，哪個副本為primary這一資訊屬於元資訊，由專門元資料伺服器維護。執行更新操作時，首先查詢元資料伺服器獲取副本的primary資訊，進一步執行資料更新流程。

• 切換副本難點有兩個方面：如何確定節點狀態以發現原primary節點出現異常(Lease機制)。切換primary後不能影響一致性(Quorum機制)。

(4) 資料同步

當發生secondary與primary不一致的情況，需要secondary向primary進行同步(reconcile)。

不一致的原因有3種：

• 網路分化等異常導致secondary落後於primary

  常用的方式是回放primary上的操作日誌(redo日誌)，追上primary的更新進度

• 某些協議下secondary是髒資料

  丟棄轉到第三種情況；或者設計基於undo日誌的方式

• secondary是一個新增副本完全沒有資料

  直接copy primary的資料，但要求同時primary能繼續提供更新服務，這就要求primary副本支援快照(snapshot)功能。即對某一刻的副本資料形成快照，然後copy快照，再使用回放日誌的方式追趕快照後的更新操作。

2.2.3 去中心化副本控制協議

去中心化副本控制協議沒有中心節點，節點之間通過平等協商達到一致。工程中唯一能應用在強一致性要求下的是paxos協議。後續介紹。

2.3 lease機制

2.3.1 基於lease的分散式cache系統

(1) 需求：分散式系統中有一個節點A儲存維護系統的元資料，系統中其他節點通過訪問A讀取修改元資料，導致A的效能成為系統瓶頸。為此，設計一種元資料cache，在各個節點上cache元資料資訊，使得：

• 減少對A的訪問，提高效能

• 各個節點cache資料始終與A一致

• 最大可能處理節點down機、網路中斷等異常

(2) 解決方案原理：

• A向各個節點發送資料的同時向節點頒發一個lease，每個lease具有一個有效期，通常是一個明確的時間點。一旦真實時間超過次時間點則lease過期

• 在lease有效期內，A保證不會修改對應資料的值。

• A在修改資料時，首先阻塞所有新的讀請求，等待之前為該資料發出的所有lease過期，然後修改資料的值

(3) 客戶端節點讀取元資料的流程

if (元資料處於本地cache && lease處於有效期內) {
    直接返回cache中的元資料;
} else {
    Result = 向A請求讀取元資料資訊;
    if (Result.Status == SUCCESS) {
        WriteToCache(Result.data, Result.lease);
    } else if (Result.Status == FAIL || Result.Status == TIMEOUT) {
        retry() or exit();
    }
}

(4) 客戶端節點修改元資料的流程

• 節點向A發起修改元資料的請求

• A收到修改請求後阻塞所有新的讀資料請求，即接受讀請求但不返回資料

• A等待所有與該元資料相關的lease超時

• A修改元資料並向節點返回修改成功

(5) 優化點

• A修改元資料時要阻塞所有新的讀請求

  這是為了防止發出新的lease而引起不斷有新的cache節點持有lease，形成活鎖。優化的手段是：一旦A進入修改流程，不是盲目遮蔽讀請求，而是對讀請求只返回資料不返回lease。造成cache節點只能讀取資料，不能cache資料。進一步的優化是返回當前已發出的lease的最大值。這樣同樣能避免活鎖問題。

• A在修改元資料時需要等待所有lease過期

  優化手段是：A主動通知各個持有lease的節點，放棄lease並清除cache中相關資料。如果收到cache節點的reply，確認協商通過，則可以提前完成修改動作；如果中間失敗或超時，則進入正常等待lease過期的流程，不會影響協議正確性。

2.3.2 lease機制的深入分析

(1) lease定義

lease是由頒發者授予的再某一有效期內的承諾。頒發者一旦發出lease，無論接收方是否收到，無論後續接收方處於何種狀態，只要lease不過期則頒發者一定嚴守承諾；另一方面，接受者在lease的有效期內可以使用頒發者的承諾，一旦lease過期則一定不能繼續使用。

(2) lease的解讀

由於lease僅僅是一種承諾，具體的承諾內容可以非常寬泛，可以是上節中資料的正確性，也可以是某種許可權。例如併發控制中同一時刻只給某一個節點頒發lease，只有持有lease才能修改資料；例如primary-secondary中持有lease的節點具有primary身份等等

(3) lease的高可用性

• 有效期的引入，非常好的解決了網路異常問題。由於lease是確定的時間點，所以可以簡單重發；一旦受到lease之後，就不再依賴網路通訊

(4) lease的時鐘同步

工程上將頒發者有效期設定的比接受者打，大過時鐘誤差，來避免對lease有效性產生影響。

2.3.3 基於lease機制確定節點狀態。

在分 布式系統中確定一個節點是否處於正常工作狀態困難的問題。由可能存在網路分化，節點的狀態無法通過網路通訊來確定的。

例如： a b c 互為副本 a為主節點，q為監控節點。q通過ping來判斷abc的狀態，認為a不能工作。就將主節點切換成b。但是事實上僅僅是ping沒收到，a自己認為自己沒有問題，就出現了 a b都覺得自己是主節點的“雙主”問題。

解決方法是q在傳送heartbeat時加上lease，表示確認了abc的狀態，並允許節點在lease有效期內正常工作。q給primary節點一個特殊的lease，表示該節點作為primary工作。一旦q希望切換primary，只需要等待之前primary的lease過期，避免出現雙主問題。

2.3.4 lease的有效期時間選擇

工程上一般選擇10秒鐘

2.4 Quorum機制

2.4.1 Write-all-read-one

對於某次更新操作Wi，只有在所有N個副本上都更新成功，才認為是一次“成功提交的更新操作”，對應的資料為“成功提交的資料”，資料版本為Vi。

缺點：

• 頻繁讀寫版本號容易成為瓶頸

• N-1個副本成功的情況下，仍然被認為更新失敗

2.4.2 Quorum定義

WARO最大程度增強讀服務可用性，最大程度犧牲寫服務的可用性。將讀寫可用性折中，就會得到Quorum機制：

Quorum機制下，某次更新Wi一旦在所有N個副本中的W個副本上成功，就稱為“成功提交的更新操作”，對應的資料為“成功提交的資料”。令R > N - W，最多需要讀取R個副本則一定能讀到Wi更新後的資料Vi。

由此可見WARO是Quorum中W = N時的一個特例。

2.4.3 讀取最新成功提交的資料

Quorum的定義基於兩個假設：

• 讀取者知道當前已提交的版本號

• 每次都是一次成功的提交

現在取消這兩個假設，分析下面這個實際問題：

N = 5, W = 3, R = 3，某一次的副本狀態為(V2 V2 V2 V1 V1)。理論上讀取任何3個副本一定能讀到最新的資料V2，但是僅讀3個副本卻無法確定讀到最新的資料。

例如讀到的是(V2 V1 V1)，因為當副本狀態為(V2 V1 V1 V1 V1)時也會讀到(V2 V1 V1)，而此時V2版本的資料是一次失敗的提交。因此只讀3個無法確定最新有效的版本是V2還是V1。

解決方案：

• 限制提交的更新操作必須嚴格遞增，只有前一個更新操作成功後才可以提交下一個。保證成功的版本號連續

• 讀取R個副本，對其中版本號最高的資料：若已存在W個，則該資料為最新結果；否則假設為X個，則繼續讀取其他副本直到成功讀取W個該版本的副本。如果無法找到W個，則第二大的版本號為最新成功提交的版本。

因此單純使用Quorum機制時，最多需要讀取R + (W - R - 1) = N個副本才能確定最新成功提交的版本。實際工程中一般使用quorum與primary-secondary結合的手段，避免需要讀取N個副本。

2.4.4 基於Quorum機制選擇primary

• 在primary-secondary協議中引入quorum機制：即primary成功更新W個副本後向使用者返回成功

• 當primary異常時需要選擇一個新的primary，之後secondary副本與primary同步資料

通常情況下切換primary由監控節點q完成，引入quorum之後，選擇新的primary的方式與讀取資料相似，即q讀取R個副本，選擇R個副本中版本號最高的副本作為新的primary。新primary與除去q選舉出的副本外，其餘的至少W個副本完成資料同步後，再作為新的primary。

蘊含的道理是：

• R個副本中版本號最高的副本一定蘊含了最新的成功提交的資料。

• 雖然不能確定版本號最高的資料 == 這個最新成功提交的資料，但新的primary立即完成了對W個副本的更新，從而使其變成了成功提交的資料

例如：N = 5 W = 3 R = 3的系統，某時刻副本狀態(V2 V2 V1 V1 V1)，此時V1是最新成功提交的資料，V2是處於中間狀態未成功提交的資料。V2是作為髒資料扔掉，還是作為新資料被同步，完全取決於能否參與q主持的新primary的選舉大會。如果q選擇(V1 V1 V1)，則在接下來的更新過程中 V2會被當成髒資料扔掉；如果q選擇(V2 V1 V1)則V2會將V1更新掉，成為最新成功的資料。

2.5 日誌技術

日誌技術不是一種分散式系統技術，但分散式系統廣泛使用日誌技術做down機恢復。

2.5.1 資料庫系統日誌回顧

資料庫的日誌分為 undo redo redo/undo no-redo/no-undo四種，這裡不做過多介紹。

2.5.2 redo與check point

通過redo log恢復down機的缺點是需要掃描整個redolog，回放所有redo日誌。解決這個問題的辦法是引入checkpoint技術，簡化模型下checkpoint就是在begin和end中間，將記憶體以某種資料組織方式dump到磁碟上。這樣down機恢復時只需要從最後一個end向前找到最近一個begin，恢復中間的記憶體狀態即可。

2.5.3 no-undo/no-redo

這種技術也叫做01目錄，即有兩個目錄，活動目錄和非活動目錄，另外還有一個主記錄，要麼“記錄目錄0”，妖魔記錄“使用目錄1”，目錄0和1記錄了各個資料在日誌檔案中的位置。

2.6 兩階段提交協議

2.7 基於MVCC的分散式事務

由於這兩個都與資料庫事務有關，且兩階段提交協議在工程中使用價值不高，均略去不談。

2.8 Paxos協議

唯一在工程中有使用價值的去中心化副本節點控制協議。過於複雜，沒看懂。

2.9 CAP理論

• Consitency

• Availiablity

• Tolerance to the Partition of network

無法設計一種分散式協議，使得完全具備CAP三個屬性。永遠只能介於三者之間折中。理論的意義是：不要妄想設計完美的分散式系統。

​針對上面的技術我特意整理了一下，有很多技術不是靠幾句話能講清楚，所以乾脆找朋友錄製了一些視訊，很多問題其實答案很簡單，但是背後的思考和邏輯不簡單，要做到知其然還要知其所以然。如果想學習Java工程化、高效能及分散式、深入淺出。微服務、Spring，MyBatis，Netty原始碼分析的朋友可以加我的Java進階群：744642380，群裡有阿里大牛直播講解技術，以及Java大型網際網路技術的視訊免費分享給大家。