[[274519]]

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 一致性

副本帶來的一致性問題

1.3.5：分布式架構系統的可視化監控方案

1、架構師是如何解決分布式架構系統監控難題的。

2、ELK是誰，從哪里來，要到哪里去?

3、京東海量數據檢索，我們一起來感受。

4、只需點擊鼠標，高逼格監控界面一鍵搞定。

5、你離互聯網架構師到底有遠?聽聽就知道。

6、架構師的技術棧應該是怎樣的?你來問，我一定答。

 

轉發 轉發 轉發 重要的事情說3遍 轉發關注我私信會發:Java架構 領取分布式架構思維導圖 以及資深架構師講解的分布式精講視頻資料(還會提供高并發，spring源碼，mybatis源碼，dubbo，netty等多個知識點的視頻技術分享!

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三個屬性。永遠只能介于三者之間折中。理論的意義是：不要妄想設計完美的分布式系統。