聊一聊分布式系統(tǒng)原理

作者：儒雅程序員 2020-01-17 09:07:14

開發(fā)

前端

分布式 在具體的工程項目中，一個節(jié)點往往是一個操作系統(tǒng)上的進程。在本文的模型中，認為節(jié)點是一個完整的、不可分的整體，如果某個程序進程實際上由若干相對獨立部分構成，則在模型中可以將一個進程劃分為多個節(jié)點。

成都創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網綜合服務，包含不限于做網站、網站建設、攀枝花網絡推廣、小程序制作、攀枝花網絡營銷、攀枝花企業(yè)策劃、攀枝花品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；成都創(chuàng)新互聯(lián)為所有大學生創(chuàng)業(yè)者提供攀枝花建站搭建服務，24小時服務熱線：028-86922220，官方網址：www.cdcxhl.com

 1 概念

1.1 模型

節(jié)點

在具體的工程項目中，一個節(jié)點往往是一個操作系統(tǒng)上的進程。在本文的模型中，認為節(jié)點是一個完整的、不可分的整體，如果某個程序進程實際上由若干相對獨立部分構成，則在模型中可以將一個進程劃分為多個節(jié)點。

異常

• 機器宕機：機器宕機是最常見的異常之一。在大型集群中每日宕機發(fā)生的概率為千分之一左右，在實踐中，一臺宕機的機器恢復的時間通常認為是24 小時，一般需要人工介入重啟機器。
• 網絡異常：消息丟失，兩片節(jié)點之間彼此完全無法通信，即出現(xiàn)了“網絡分化”;
• 消息亂序，有一定的概率不是按照發(fā)送時的順序依次到達目的節(jié)點，考慮使用序列號等機制處理網絡消息的亂序問題，使得無效的、過期的網絡消息不影響系統(tǒng)的正確性;
• 數(shù)據錯誤;不可靠的TCP，TCP 協(xié)議為應用層提供了可靠的、面向連接的傳輸服務，但在分布式系統(tǒng)的協(xié)議設計中不能認為所有網絡通信都基于TCP 協(xié)議則通信就是可靠的。
• TCP協(xié)議只能保證同一個TCP 鏈接內的網絡消息不亂序，TCP 鏈接之間的網絡消息順序則無法保證。
• 分布式三態(tài)：如果某個節(jié)點向另一個節(jié)點發(fā)起RPC(Remote procedure call)調用，即某個節(jié)點A 向另一個節(jié)點B 發(fā)送一個消息，節(jié)點B 根據收到的消息內容完成某些操作，并將操作的結果通過另一個消息返回給節(jié)點A，那么這個RPC 執(zhí)行的結果有三種狀態(tài)：“成功”、“失敗”、“超時(未知)”，稱之為分布式系統(tǒng)的三態(tài)。
• 存儲數(shù)據丟失:對于有狀態(tài)節(jié)點來說，數(shù)據丟失意味著狀態(tài)丟失，通常只能從其他節(jié)點讀取、恢復存儲的狀態(tài)。
• *異常處理原則*：被大量工程實踐所檢驗過的異常處理黃金原則是：任何在設計階段考慮到的異常情況一定會在系統(tǒng)實際運行中發(fā)生，但在系統(tǒng)實際運行遇到的異常卻很有可能在設計時未能考慮，所以，除非需求指標允許，在系統(tǒng)設計時不能放過任何異常情況。

1.2 副本

副本(replica/copy)指在分布式系統(tǒng)中為數(shù)據或服務提供的冗余。對于數(shù)據副本指在不同的節(jié)點上持久化同一份數(shù)據，當出現(xiàn)某一個節(jié)點的存儲的數(shù)據丟失時，可以從副本上讀到數(shù)據。

數(shù)據副本是分布式系統(tǒng)解決數(shù)據丟失異常的唯一手段。另一類副本是服務副本，指數(shù)個節(jié)點提供某種相同的服務，這種服務一般并不依賴于節(jié)點的本地存儲，其所需數(shù)據一般來自其他節(jié)點。

副本協(xié)議是貫穿整個分布式系統(tǒng)的理論核心。

副本一致性

分布式系統(tǒng)通過副本控制協(xié)議，使得從系統(tǒng)外部讀取系統(tǒng)內部各個副本的數(shù)據在一定的約束條件下相同，稱之為副本一致性(consistency)。副本一致性是針對分布式系統(tǒng)而言的，不是針對某一個副本而言。

• 強一致性(strong consistency)：任何時刻任何用戶或節(jié)點都可以讀到最近一次成功更新的副本數(shù)據。強一致性是程度最高的一致性要求，也是實踐中最難以實現(xiàn)的一致性。

單調一致性(monotonic consistency)：任何時刻，任何用戶一旦讀到某個數(shù)據在某次更新后的值，這個用戶不會再讀到比這個值更舊的值。

• 單調一致性是弱于強一致性卻非常實用的一種一致性級別。因為通常來說，用戶只關心從己方視角觀察到的一致性，而不會關注其他用戶的一致性情況。
• 會話一致性(session consistency)：任何用戶在某一次會話內一旦讀到某個數(shù)據在某次更新后的值，這個用戶在這次會話過程中不會再讀到比這個值更舊的值。

會話一致性通過引入會話的概念，在單調一致性的基礎上進一步放松約束，會話一致性只保證單個用戶單次會話內數(shù)據的單調修改，對于不同用戶間的一致性和同一用戶不同會話間的一致性沒有保障。

實踐中有許多機制正好對應會話的概念，例如php 中的session 概念。

• 最終一致性(eventual consistency)：最終一致性要求一旦更新成功，各個副本上的數(shù)據最終將達 到完全一致的狀態(tài)，但達到完全一致狀態(tài)所需要的時間不能保障。

對于最終一致性系統(tǒng)而言，一個用戶只要始終讀取某一個副本的數(shù)據，則可以實現(xiàn)類似單調一致性的效果，但一旦用戶更換讀取的副本，則無法保障任何一致性。

• 弱一致性(week consistency)：一旦某個更新成功，用戶無法在一個確定時間內讀到這次更新的值，且即使在某個副本上讀到了新的值，也不能保證在其他副本上可以讀到新的值。

弱一致性系統(tǒng)一般很難在實際中使用，使用弱一致性系統(tǒng)需要應用方做更多的工作從而使得系統(tǒng)可用。

1.3 衡量分布式系統(tǒng)的指標

• 性能：系統(tǒng)的吞吐能力，指系統(tǒng)在某一時間可以處理的數(shù)據總量，通常可以用系統(tǒng)每秒處理的總的數(shù)據量來衡量;

系統(tǒng)的響應延遲，指系統(tǒng)完成某一功能需要使用的時間;

系統(tǒng)的并發(fā)能力，指系統(tǒng)可以同時完成某一功能的能力，通常也用QPS(query per second)來衡量。

上述三個性能指標往往會相互制約，追求高吞吐的系統(tǒng)，往往很難做到低延遲;系統(tǒng)平均響應時間較長時，也很難提高QPS。

• 可用性：系統(tǒng)的可用性(availability)指系統(tǒng)在面對各種異常時可以正確提供服務的能力。

系統(tǒng)的可用性可以用系統(tǒng)停服務的時間與正常服務的時間的比例來衡量，也可以用某功能的失敗次數(shù)與成功次數(shù)的比例來衡量?？捎眯允欠植际降闹匾笜?，衡量了系統(tǒng)的魯棒性，是系統(tǒng)容錯能力的體現(xiàn)。

• 可擴展性：系統(tǒng)的可擴展性(scalability)指分布式系統(tǒng)通過擴展集群機器規(guī)模提高系統(tǒng)性能(吞吐、延遲、并發(fā))、存儲容量、計算能力的特性。好的分布式系統(tǒng)總在追求“線性擴展性”，也就是使得系統(tǒng)的某一指標可以隨著集群中的機器數(shù)量線性增長。
• 一致性：分布式系統(tǒng)為了提高可用性，總是不可避免的使用副本的機制，從而引發(fā)副本一致性的問題。越是強的一致的性模型，對于用戶使用來說使用起來越簡單。

2 分布式系統(tǒng)原理

2.1 數(shù)據分布方式

所謂分布式系統(tǒng)顧名思義就是利用多臺計算機協(xié)同解決單臺計算機所不能解決的計算、存儲等問題。

單機系統(tǒng)與分布式系統(tǒng)的最大的區(qū)別在于問題的規(guī)模，即計算、存儲的數(shù)據量的區(qū)別。

將一個單機問題使用分布式解決，首先要解決的就是如何將問題拆解為可以使用多機分布式解決，使得分布式系統(tǒng)中的每臺機器負責原問題的一個子集。由于無論是計算還是存儲，其問題輸入對象都是數(shù)據，所以如何拆解分布式系統(tǒng)的輸入數(shù)據成為分布式系統(tǒng)的基本問題。

哈希方式

哈希分布數(shù)據的缺點同樣明顯，突出表現(xiàn)為可擴展性不高，一旦集群規(guī)模需要擴展，則幾乎所有的數(shù)據需要被遷移并重新分布。工程中，擴展哈希分布數(shù)據的系統(tǒng)時，往往使得集群規(guī)模成倍擴展，按照數(shù)據重新計算哈希，這樣原本一臺機器上的數(shù)據只需遷移一半到另一臺對應的機器上即可完成擴展。

針對哈希方式擴展性差的問題，一種思路是不再簡單的將哈希值與機器做除法取模映射，而是將對應關系作為元數(shù)據由專門的元數(shù)據服務器管理.同時，哈希值取模個數(shù)往往大于機器個數(shù)，這樣同一臺機器上需要負責多個哈希取模的余數(shù)。但需要以較復雜的機制維護大量的元數(shù)據。哈希分布數(shù)據的另一個缺點是，一旦某數(shù)據特征值的數(shù)據嚴重不均，容易出現(xiàn)“數(shù)據傾斜”(data skew)問題。

哈希分布數(shù)據的另一個缺點是，一旦某數(shù)據特征值的數(shù)據嚴重不均，容易出現(xiàn)“數(shù)據傾斜”(data skew)問題

按數(shù)據范圍分布

按數(shù)據范圍分布是另一個常見的數(shù)據分布式，將數(shù)據按特征值的值域范圍劃分為不同的區(qū)間，使得集群中每臺(組)服務器處理不同區(qū)間的數(shù)據。

工程中，為了數(shù)據遷移等負載均衡操作的方便，往往利用動態(tài)劃分區(qū)間的技術，使得每個區(qū)間中服務的數(shù)據量盡量的一樣多。當某個區(qū)間的數(shù)據量較大時，通過將區(qū)間“分裂”的方式拆分為兩個區(qū)間，使得每個數(shù)據區(qū)間中的數(shù)據量都盡量維持在一個較為固定的閾值之下。

一般的，往往需要使用專門的服務器在內存中維護數(shù)據分布信息，稱這種數(shù)據的分布信息為一種元信息。甚至對于大規(guī)模的集群，由于元信息的規(guī)模非常龐大，單臺 計算機無法獨立維護，需要使用多臺機器作為元信息服務器。

按數(shù)據量分布

數(shù)據量分布數(shù)據與具體的數(shù)據特征無關，而是將數(shù)據視為一個順序增長的文件，并將這個文件按照某一較為固定的大小劃分為若干數(shù)據塊(chunk)，不同的數(shù)據塊分布到不同的服務器上

與按數(shù)據范圍分布數(shù)據的方式類似的是，按數(shù)據量分布數(shù)據也需要記錄數(shù)據塊的具體分布情況，并將該分布信息作為元數(shù)據使用元數(shù)據服務器管理。

由于與具體的數(shù)據內容無關，按數(shù)據量分布數(shù)據的方式一般沒有數(shù)據傾斜的問題，數(shù)據總是被均勻切分并分布到集群中。

當集群需要重新負載均衡時，只需通過遷移數(shù)據塊即可完成。集群擴容也沒有太大的限制，只需將部分數(shù)據庫遷移到新加入的機器上即可以完成擴容。

按數(shù)據量劃分數(shù)據的缺點是需要管理較為復雜的元信息，與按范圍分布數(shù)據的方式類似，當集群規(guī)模較大時，元信息的數(shù)據量也變得很大，高效的管理元信息成為新的課題。

一致性哈希

一致性哈希(consistent hashing)是另一個種在工程中使用較為廣泛的數(shù)據分布方式。一致性哈希最初在P2P 網絡中作為分布式哈希表(DHT)的常用數(shù)據分布算法。

一致性哈希的基本方式是使用一個哈希函數(shù)計算數(shù)據或數(shù)據特征的哈希值，令該哈希函數(shù)的輸出值域為一個封閉的環(huán)，即哈希函數(shù)輸出的最大值是最小值的前序。將節(jié)點隨機分布到這個環(huán)上，每個節(jié)點負責處理從自己開始順時針至下一個節(jié)點的全部哈希值域上的數(shù)據。

使用一致性哈希的方式需要將節(jié)點在一致性哈希環(huán)上的位置作為元信息加以管理，這點比直接使用哈希分布數(shù)據的方式要復雜。然而，節(jié)點的位置信息只于集群中的機器規(guī)模相關，其元信息的量通常比按數(shù)據范圍分布數(shù)據和按數(shù)據量分布數(shù)據的元信息量要小很多。

為此一種常見的改進算法是引入虛節(jié)點(virtual node)的概念，系統(tǒng)初始時就創(chuàng)建許多虛節(jié)點，虛節(jié)點的個數(shù)一般遠大于未來集群中機器的個數(shù)，將虛節(jié)點均勻分布到一致性哈希值域環(huán)上，其功能與基本一致性哈希算法中的節(jié)點相同。為每個節(jié)點分配若干虛節(jié)點。

操作數(shù)據時，首先通過數(shù)據的哈希值在環(huán)上找到對應的虛節(jié)點，進而查找元數(shù)據找到對應的真實節(jié)點。使用虛節(jié)點改進有多個優(yōu)點。

首先，一旦某個節(jié)點不可用，該節(jié)點將使得多個虛節(jié)點不可用，從而使得多個相鄰的真實節(jié)點負載失效節(jié)點的壓里。同理，一旦加入一個新節(jié)點，可以分配多個虛節(jié)點，從而使得新節(jié)點可以 負載多個原有節(jié)點的壓力，從全局看，較容易實現(xiàn)擴容時的負載均衡。

副本與數(shù)據分布

分布式系統(tǒng)容錯、提高可用性的基本手段就是使用副本。對于數(shù)據副本的分布方式主要影響系統(tǒng)的可擴展性。一種基本的數(shù)據副本策略是以機器為單位，若干機器互為副本，副本機器之間的數(shù)據完全相同。這種策略適用于上述各種數(shù)據分布方式。其優(yōu)點是非常簡單，其缺點是恢復數(shù)據的效率不高、可擴展性也不高。

更合適的做法不是以機器作為副本單位，而是將數(shù)據拆為較合理的數(shù)據段，以數(shù)據段為單位作為副本。

實踐中，常常使得每個數(shù)據段的大小盡量相等且控制在一定的大小以內。數(shù)據段有很多不同的稱謂，segment，fragment，chunk，partition 等等。數(shù)據段的選擇與數(shù)據分布方式直接相關。

對于哈希分數(shù)據的方式，每個哈希分桶后的余數(shù)可以作為一個數(shù)據段，為了控制數(shù)據段的大小，常常使得分桶個數(shù)大于集群規(guī)模。一旦將數(shù)據分為數(shù)據段，則可以以數(shù)據段為單位管理副本，從而副本與機器不再硬相關，每臺機器都可以負責一定數(shù)據段的副本。

一旦副本分布與機器無關，數(shù)據丟失后的恢復效率將非常高。這是因為，一旦某臺機器的數(shù)據丟失，其上數(shù)據段的副本將分布在整個集群的所有機器中，而不是僅在幾個副本機器中，從而可以從整個集群同時拷貝恢復數(shù)據，而集群中每臺數(shù)據源機器都可以以非常低的資源做拷貝。作為恢復數(shù)據源的機器即使都限速1MB/s，若有100 臺機器參與恢復，恢復速度也能達到100MB/s。

再者，副本分布與機器無關也利于集群容錯。如果出現(xiàn)機器宕機，由于宕機機器上的副本分散于整個集群，其壓力也自然分散到整個集群。

最后，副本分布與機器無關也利于集群擴展。理論上，設集群規(guī)模 為N 臺機器，當加入一臺新的機器時，只需從各臺機器上遷移1/N – 1/N+1 比例的數(shù)據段到新機器即實現(xiàn)了新的負載均衡。由于是從集群中各機器遷移數(shù)據，與數(shù)據恢復同理，效率也較高。

工程中，完全按照數(shù)據段建立副本會引起需要管理的元數(shù)據的開銷增大，副本維護的難度也相應增大。一種折中的做法是將某些數(shù)據段組成一個數(shù)據段分組，按數(shù)據段分組為粒度進行副本管理。這樣做可以將副本粒度控制在一個較為合適的范圍內。

本地化計算

在分布式系統(tǒng)中，數(shù)據的分布方式也深深影響著計算的分布方式。在分布式系統(tǒng)中計算節(jié)點和保存計算數(shù)據的存儲節(jié)點可以在同一臺物理機器上，也可以位于不同的物理機器。

如果計算節(jié)點和存儲節(jié)點位于不同的物理機器則計算的數(shù)據需要通過網絡傳輸，此種方式的開銷很大，甚至網絡帶寬會成為系統(tǒng)的總體瓶頸。

另一種思路是，將計算盡量調度到與存儲節(jié)點在同一臺物理機器上的計算節(jié)點上進行，這稱之為本地化計算。本地化計算是計算調度的一種重要優(yōu)化，其體現(xiàn)了一種重要的分布式調度思想：“移動數(shù)據不如移動計算”。

數(shù)據分布方式的選擇

在實際工程實踐中，可以根據需求及實施復雜度合理選擇數(shù)據分布方式。另外，數(shù)據分布方式是可以靈活組合使用的，往往可以兼?zhèn)涓鞣N方式的優(yōu)點，收到較好的綜合效果。

例：數(shù)據傾斜問題，在按哈希分數(shù)據的基礎上引入按數(shù)據量分布數(shù)據的方式，解決該數(shù)據傾斜問題。按用戶id 的哈希值分數(shù)據，當某個用戶id 的數(shù)據量特別大時，該用戶的數(shù)據始終落在某一臺機器上。此時，引入按數(shù)據量分布數(shù)據的方式，統(tǒng)計用戶的數(shù)據量，并按某一閾值將用戶的數(shù)據切為多個均勻的數(shù)據段，將這些數(shù)據段分布到集群中去。由于大部分用戶的數(shù)據量不會超過閾值，所以元數(shù)據中僅僅保存超過閾值的用戶的數(shù)據段分布信息，從而可以控制元數(shù)據的規(guī)模。這種哈希分布數(shù)據方式與按數(shù)據量分布數(shù)據方式組合使用的方案，在某真實系統(tǒng)中使用，取得了較好的效果。

2.2 基本副本協(xié)議

副本控制協(xié)議指按特定的協(xié)議流程控制副本數(shù)據的讀寫行為，使得副本滿足一定的可用性和一致性要求的分布式協(xié)議。副本控制協(xié)議要具有一定的對抗異常狀態(tài)的容錯能力，從而使得系統(tǒng)具有一定的可用性，同時副本控制協(xié)議要能提供一定一致性級別。由CAP 原理(在2.9 節(jié)詳細分析)可知，要設計一種滿足強一致性，且在出現(xiàn)任何網絡異常時都可用的副本協(xié)議是不可能的。為此，實際中的副本控制協(xié)議總是在可用性、一致性與性能等各要素之間按照具體需求折中。

副本控制協(xié)議可以分為兩大類：“中心化(centralized)副本控制協(xié)議”和“去中心化(decentralized)副本控制協(xié)議”。

中心化副本控制協(xié)議

中心化副本控制協(xié)議的基本思路是由一個中心節(jié)點協(xié)調副本數(shù)據的更新、維護副本之間的一致性。

圖給出了中心化副本協(xié)議的通用架構。中心化副本控制協(xié)議的優(yōu)點是協(xié)議相對較為簡單，所有的副本相關的控制交由中心節(jié)點完成。并發(fā)控制將由中心節(jié)點完成，從而使得一個分布式并發(fā)控制問題，簡化為一個單機并發(fā)控制問題。

所謂并發(fā)控制，即多個節(jié)點同時需要修改副本數(shù)據時，需要解決“寫寫”、“讀寫”等并發(fā)沖突。單機系統(tǒng)上常用加鎖等方式進行并發(fā)控制。對于分布式并發(fā)控制，加鎖也是一個常用的方法，但如果沒有中心節(jié)點統(tǒng)一進行鎖管理，就需要完全分布式化的鎖系統(tǒng)，會使得協(xié)議非常復雜。

中心化副本控制協(xié)議的缺點是系統(tǒng)的可用性依賴于中心化節(jié)點，當中心節(jié)點異?；蚺c中心節(jié)點通信中斷時，系統(tǒng)將失去某些服務(通常至少失去更新服務)，所以中心化副本控制協(xié)議的缺點正是存在一定的停服務時間。

primary-secondary 協(xié)議

在primary-secondary 類型的協(xié)議中，副本被分為兩大類，其中有且僅有一個副本作為primary 副本，除primary 以外的副本都作為secondary 副本。維護primary 副本的節(jié)點作為中心節(jié)點，中心節(jié)點負責維護數(shù)據的更新、并發(fā)控制、協(xié)調副本的一致性。

Primary-secondary 類型的協(xié)議一般要解決四大類問題：數(shù)據更新流程、數(shù)據讀取方式、Primary 副本的確定和切換、數(shù)據同步(reconcile)。

數(shù)據更新基本流程

• 數(shù)據更新都由primary 節(jié)點協(xié)調完成。
• 外部節(jié)點將更新操作發(fā)給primary 節(jié)點
• primary 節(jié)點進行并發(fā)控制即確定并發(fā)更新操作的先后順序
• primary 節(jié)點將更新操作發(fā)送給secondary 節(jié)點
• primary 根據secondary 節(jié)點的完成情況決定更新是否成功并將結果返回外部節(jié)點

在工程實踐中，如果由primary 直接同時發(fā)送給其他N 個副本發(fā)送數(shù)據，則每個 secondary 的更新吞吐受限于primary 總的出口網絡帶寬，最大為primary 網絡出口帶寬的1/N。

為了解決這個問題，有些系統(tǒng)(例如，GFS)，使用接力的方式同步數(shù)據，即primary 將更新發(fā)送給第一 個secondary 副本，第一個secondary 副本發(fā)送給第二secondary 副本，依次類推。

數(shù)據讀取方式

數(shù)據讀取方式也與一致性高度相關。如果只需要最終一致性，則讀取任何副本都可以滿足需求。

如果需要會話一致性，則可以為副本設置版本號，每次更新后遞增版本號，用戶讀取副本時驗證版本號，從而保證用戶讀到的數(shù)據在會話范圍內單調遞增。使用primary-secondary 比較困難的是實現(xiàn)強一致性。

由于數(shù)據的更新流程都是由primary 控制的，primary 副本上的數(shù)據一定是最新的，所以 如果始終只讀primary 副本的數(shù)據，可以實現(xiàn)強一致性。如果只讀primary 副本，則secondary 副本將不提供讀服務。

實踐中，如果副本不與機器綁定，而是按照數(shù)據段為單位維護副本，僅有primary 副本提供讀服務在很多場景下并不會造出機器資源浪費。

將副本分散到集群中個，假設primary 也是隨機的確定的，那么每臺機器上都有一些數(shù)據的primary 副本，也有另一些數(shù)據段的secondary 副本。從而某臺服務器實際都提供讀寫服務。

由primary 控制節(jié)點secondary 節(jié)點的可用性。當primary 更新某個secondary 副本不成功時，primary 將該secondary 副本標記為不可用，從而用戶不再讀取該不可用的副本。不可用的 secondary 副本可以繼續(xù)嘗試與primary 同步數(shù)據，當與primary 完成數(shù)據同步后，primary 可以副本標記為可用。

這種方式使得所有的可用的副本，無論是primary 還是secondary 都是可讀的，且在一個確定的時間內，某secondary 副本要么更新到與primary 一致的最新狀態(tài)，要么被標記為不可用，從而符合較高的一致性要求。這種方式依賴于一個中心元數(shù)據管理系統(tǒng)，用于記錄哪些副本可用，哪些副本不可用。某種意義上，該方式通過降低系統(tǒng)的可用性來提高系統(tǒng)的一致性。

primary 副本的確定與切換

在primary-secondary 類型的協(xié)議中，另一個核心的問題是如何確定primary 副本，尤其是在原primary 副本所在機器出現(xiàn)宕機等異常時，需要有某種機制切換primary 副本，使得某個secondary 副本成為新的primary 副本。

通常的，在primary-secondary 類型的分布式系統(tǒng)中，哪個副本是primary 這一信息都屬于元信息，由專門的元數(shù)據服務器維護。執(zhí)行更新操作時，首先查詢元數(shù)據服務器獲取副本的primary 信息，從而進一步執(zhí)行數(shù)據更新流程。

由于分布式系統(tǒng)中可靠的發(fā)現(xiàn)節(jié)點異常是需要一定的探測時間的，這樣的探測時間通常是10 秒級別，這也意味著一旦primary 異常，最多需要10 秒級別的發(fā)現(xiàn)時間，系統(tǒng)才能開始primary 的切換，在這10 秒時間內，由于沒有primary，系統(tǒng)不能提供更 新服務，如果系統(tǒng)只能讀primary 副本，則這段時間內甚至不能提供讀服務。從這里可以看到，primary-backup 類副本協(xié)議的最大缺點就是由于primary 切換帶來的一定的停服務時間。

數(shù)據同步

不一致的secondary 副本需要與primary 進行同步(reconcile)。

通常不一致的形式有三種：

一、由于網絡分化等異常，secondary 上的數(shù)據落后于primary 上的數(shù)據。

二、在某些協(xié)議下，secondary 上的數(shù)據有可能是臟數(shù)據，需要被丟棄。所謂臟數(shù)據是由于primary 副本沒有進行某一更新操作，而secondary 副本上反而進行的多余的修改操作，從而造成secondary 副本數(shù)據錯誤。

三、secondary 是一個新增加的副本，完全沒有數(shù)據，需要從其他副本上拷貝數(shù)據。

對于第一種secondary 數(shù)據落后的情況，常見的同步方式是回放primary 上的操作日志(通常是redo 日志)，從而追上primary 的更新進度。

對于臟數(shù)據的情況，較好的做法是設計的分布式協(xié)議不產生臟數(shù)據。如果協(xié)議一定有產生臟數(shù)據的可能，則也應該使得產生臟數(shù)據的概率降到非常低得情況，從而一旦發(fā)生臟數(shù)據的情況可以簡單的直接丟棄有臟數(shù)據的副本，這樣相當于副本沒有數(shù)據。

另外，也可以設計一些基于undo 日志的方式從而可以刪除臟數(shù)據。如果secondary 副本完全沒有數(shù)據，則常見的做法是直接拷貝primary 副本的數(shù)據，這種方法往往比回放日志追更新進度的方法快很多。但拷貝數(shù)據時primary 副本需要能夠繼續(xù)提供更新服務，這就要求primary 副本支持快照(snapshot)功能。即對某一刻的副本數(shù)據形成快照，然后拷貝快照，拷貝完成后使用回放日志的方式追快照形成后的更新操作。

去中心化副本控制協(xié)議

去中心化副本控制協(xié)議沒有中心節(jié)點，協(xié)議中所有的節(jié)點都是完全對等的，節(jié)點之間通過平等協(xié)商達到一致。從而去中心化協(xié)議沒有因為中心化節(jié)點異常而帶來的停服務等問題。

去中心化協(xié)議的最大的缺點是協(xié)議過程通常比較復雜。尤其當去中心化協(xié)議需要實現(xiàn)強一致性時，協(xié)議流程變得復雜且不容易理解。由于流程的復雜，去中心化協(xié)議的效率或者性能一般也較中心化協(xié)議低。一個不恰當?shù)谋确骄褪?，中心化副本控制協(xié)議類似專制制度，系統(tǒng)效率高但高度依賴于中心節(jié)點，一旦中心節(jié)點異常，系統(tǒng)受到的影響較大;去中心化副本控制協(xié)議類似民主制度，節(jié)點集體協(xié)商，效率低下，但個別節(jié)點的異常不會對系統(tǒng)總體造成太大影響。

2.3 Lease 機制

Lease 機制是最重要的分布式協(xié)議，廣泛應用于各種實際的分布式系統(tǒng)中。

基于lease 的分布式cache 系統(tǒng)

基本的問題背景如下：在一個分布式系統(tǒng)中，有一個中心服務器節(jié)點，中心服務器存儲、維護著一些數(shù)據，這些數(shù)據是系統(tǒng)的元數(shù)據。系統(tǒng)中其他的節(jié)點通過訪問中心服務器節(jié)點讀取、修改其上的元數(shù)據。

由于系統(tǒng)中各種操作都依賴于元數(shù)據，如果每次讀取元數(shù)據的操作都訪問中心服務器 節(jié)點，那么中心服務器節(jié)點的性能成為系統(tǒng)的瓶頸。為此，設計一種元數(shù)據cache，在各個節(jié)點上 cache 元數(shù)據信息，從而減少對中心服務器節(jié)點的訪問，提高性能。

另一方面，系統(tǒng)的正確運行嚴格依賴于元數(shù)據的正確，這就要求各個節(jié)點上cache 的數(shù)據始終與中心服務器上的數(shù)據一致，cache 中的數(shù)據不能是舊的臟數(shù)據。最后，設計的cache 系統(tǒng)要能最大可能的處理節(jié)點宕機、網絡中斷等異常，最大程度的提高系統(tǒng)的可用性。

為此，利用lease 機制設計一套cache 系統(tǒng)，其基本原理為如下。

中心服務器在向各節(jié)點發(fā)送數(shù)據時同時向節(jié)點頒發(fā)一個lease。每個lease 具有一個有效期，和信用卡上的有效期類似，lease 上的 有效期通常是一個明確的時間點，例如12:00:10，一旦真實時間超過這個時間點，則lease 過期失效。這樣lease 的有效期與節(jié)點收到lease 的時間無關，節(jié)點可能收到lease 時該lease 就已經過期失效。這里首先假設中心服務器與各節(jié)點的時鐘是同步的，在下節(jié)中討論時鐘不同步對lease 的影響。中心服務器發(fā)出的lease 的含義為：在lease 的有效期內，中心服務器保證不會修改對應數(shù)據的值。因此，節(jié)點收到數(shù)據和lease 后，將數(shù)據加入本地Cache，一旦對應的lease 超時，節(jié)點將對應的本地cache 數(shù)據刪除。中心服務器在修改數(shù)據時，首先阻塞所有新的讀請求，并等待之前為該數(shù)據發(fā)出的所有l(wèi)ease 超時過期，然后修改數(shù)據的值。

基于lease 的cache，客戶端節(jié)點讀取元數(shù)據

1. 判斷元數(shù)據是否已經處于本地cache 且lease 處于有效期內1.1 是：直接返回cache 中的元數(shù)據1.2 否：向中心服務器節(jié)點請求讀取元數(shù)據信息1.2.1 服務器收到讀取請求后，返回元數(shù)據及一個對應的lease 1.2.2 客戶端是否成功收到服務器返回的數(shù)據 1.2.2.1 失敗或超時：退出流程，讀取失敗，可重試1.2.2.2 成功：將元數(shù)據與該元數(shù)據的lease 記錄到內存中，返回元數(shù)據
2. 基于lease 的cache，客戶端節(jié)點修改元數(shù)據流程2.1 節(jié)點向服務器發(fā)起修改元數(shù)據請求。2.2 服務器收到修改請求后，阻塞所有新的讀數(shù)據請求，即接收讀請求，但不返回數(shù)據。2.3 服務器等待所有與該元數(shù)據相關的lease 超時。2.4 服務器修改元數(shù)據并向客戶端節(jié)點返回修改成功。

上述機制可以保證各個節(jié)點上的cache 與中心服務器上的中心始終一致。這是因為中心服務器節(jié)點在發(fā)送數(shù)據的同時授予了節(jié)點對應的lease，在lease 有效期內，服務器不會修改數(shù)據，從而客戶端節(jié)點可以放心的在lease 有效期內cache 數(shù)據。上述lease 機制可以容錯的關鍵是：服務器一旦 發(fā)出數(shù)據及l(fā)ease，無論客戶端是否收到，也無論后續(xù)客戶端是否宕機，也無論后續(xù)網絡是否正常，服務器只要等待lease 超時，就可以保證對應的客戶端節(jié)點不會再繼續(xù)cache 數(shù)據，從而可以放心的修改數(shù)據而不會破壞cache 的一致性。

上述基礎流程有一些性能和可用性上的問題，但可以很容易就優(yōu)化改性。優(yōu)化點一：服務器在修改元數(shù)據時首先要阻塞所有新的讀請求，造成沒有讀服務。這是為了防止發(fā)出新的lease 從而引起不斷有新客戶端節(jié)點持有l(wèi)ease 并緩存著數(shù)據，形成“活鎖”。優(yōu)化的方法很簡單，服務器在進入修改數(shù)據流程后，一旦收到讀請求則只返回數(shù)據但不頒發(fā)lease。從而造成在修改流程執(zhí)行的過程中，客戶端可以讀到元數(shù)據，只是不能緩存元數(shù)據。進一步的優(yōu)化是，當進入修改流程，服務器頒發(fā)的lease 有效期限選擇為已發(fā)出的lease 的最大有效期限。這樣做，客戶端可以繼續(xù)在服務器進入修改流程后繼續(xù)緩存元數(shù)據，但服務器的等待所有l(wèi)ease 過期的時間也不會因為頒發(fā)新的lease 而不斷延長。

最后，=cache 機制與多副本機制的區(qū)別。Cache 機制與多副本機制的相似之處都 是將一份數(shù)據保存在多個節(jié)點上。但Cache 機制卻要簡單許多，對于cache 的數(shù)據，可以隨時刪除丟棄，并命中cache 的后果僅僅是需要訪問數(shù)據源讀取數(shù)據;然而副本機制卻不一樣，副本是不能隨意丟棄的，每失去一個副本，服務質量都在下降，一旦副本數(shù)下降到一定程度，則往往服務將不再可用。

lease 機制的分析

lease 的定義：Lease 是由頒發(fā)者授予的在某一有效期內的承諾。頒發(fā)者一旦發(fā)出lease，則無論接受方是否收到，也無論后續(xù)接收方處于何種狀態(tài)，只要lease 不過期，頒發(fā)者一定嚴守承諾;另一方面，接收方在lease 的有效期內可以使用頒發(fā)者的承諾，但一旦lease 過期，接收方一定不能繼續(xù)使用頒發(fā)者的承諾。

Lease 機制具有很高的容錯能力。首先，通過引入有效期，Lease 機制能否非常好的容錯網絡異常。Lease 頒發(fā)過程只依賴于網絡可以單向通信，即使接收方無法向頒發(fā)者發(fā)送消息，也不影響lease 的頒發(fā)。

由于lease 的有效期是一個確定的時間點，lease 的語義與發(fā)送lease 的具體時間無關，所以 同一個lease 可以被頒發(fā)者不斷重復向接受方發(fā)送。即使頒發(fā)者偶爾發(fā)送lease 失敗，頒發(fā)者也可以 簡單的通過重發(fā)的辦法解決。一旦lease 被接收方成功接受，后續(xù)lease 機制不再依賴于網絡通信，即使網絡完全中斷l(xiāng)ease 機制也不受影響。

再者，Lease 機制能較好的容錯節(jié)點宕機。如果頒發(fā)者宕機，則宕機的頒發(fā)者通常無法改變之前的承諾，不會影響lease 的正確性。在頒發(fā)者機恢復后，如果頒發(fā)者恢復出了之前的lease 信息，頒發(fā)者可以繼續(xù)遵守lease 的承諾。如果頒發(fā)者無法恢復lease 信息，則只需等待一個最大的lease 超時時間就可以使得所有的lease 都失效，從而不破壞lease機制。

例如上節(jié)中的cache 系統(tǒng)的例子中，一旦服務器宕機，肯定不會修改元數(shù)據，重新恢復后，只需等待一個最大的lease 超時時間，所有節(jié)點上的緩存信息都將被清空。

對于接受方宕機的情況，頒發(fā)者 不需要做更多的容錯處理，只需等待lease 過期失效，就可以收回承諾，實踐中也就是收回之前賦予的權限、身份等。最后，lease 機制不依賴于存儲。頒發(fā)者可以持久化頒發(fā)過的lease 信息，從而在 宕機恢復后可以使得在有效期的lease 繼續(xù)有效。但這對于lease 機制只是一個優(yōu)化，如之前的分析，即使頒發(fā)者沒有持久化lease 信息，也可以通過等待一個最大的lease 時間的方式使得之前所有頒發(fā) 的lease 失效，從而保證機制繼續(xù)有效。

Lease 機制依賴于有效期，這就要求頒發(fā)者和接收者的時鐘是同步的。一方面，如果頒發(fā)者的 時鐘比接收者的時鐘慢，則當接收者認為lease 已經過期的時候，頒發(fā)者依舊認為lease 有效。接收者可以用在lease 到期前申請新的lease 的方式解決這個問題。另一方面，如果頒發(fā)者的時鐘比接收 者的時鐘快，則當頒發(fā)者認為lease 已經過期的時候，接收者依舊認為lease 有效，頒發(fā)者可能將lease 頒發(fā)給其他節(jié)點，造成承諾失效，影響系統(tǒng)的正確性。對于這種時鐘不同步，實踐中的通常做法是將頒發(fā)者的有效期設置得比接收者的略大，只需大過時鐘誤差就可以避免對lease 的有效性的影響。

基于lease 機制確定節(jié)點狀態(tài)

分布式協(xié)議依賴于對節(jié)點狀態(tài)認知的全局一致性，即一旦節(jié)點Q 認為某個節(jié)點 A 異常，則節(jié)點A 也必須認為自己異常，從而節(jié)點A 停止作為primary，避免“雙主”問題的出現(xiàn)。

解決這種問題有兩種思路，第一、設計的分布式協(xié)議可以容忍“雙主”錯誤，即不依賴于對節(jié)點狀 態(tài)的全局一致性認識，或者全局一致性狀態(tài)是全體協(xié)商后的結果;

第二、利用lease 機制。對于第一 種思路即放棄使用中心化的設計，而改用去中心化設計，超過本節(jié)的討論范疇。下面著重討論利用 lease 機制確定節(jié)點狀態(tài)。

由中心節(jié)點向其他節(jié)點發(fā)送lease，若某個節(jié)點持有有效的lease，則認為該節(jié)點正常可以提供服 務。用于例2.3.1 中，節(jié)點A、B、C 依然周期性的發(fā)送heart beat 報告自身狀態(tài)，節(jié)點Q 收到heart beat 后發(fā)送一個lease，表示節(jié)點Q 確認了節(jié)點A、B、C 的狀態(tài)，并允許節(jié)點在lease 有效期內正常工 作。節(jié)點Q 可以給primary 節(jié)點一個特殊的lease，表示節(jié)點可以作為primary 工作。一旦節(jié)點Q 希望切換新的primary，則只需等前一個primary 的lease 過期，則就可以安全的頒發(fā)新的lease 給新的 primary 節(jié)點，而不會出現(xiàn)“雙主”問題。

在實際系統(tǒng)中，若用一個中心節(jié)點發(fā)送lease 也有很大的風險，一旦該中心節(jié)點宕機或網絡異常，則所有的節(jié)點沒有l(wèi)ease，從而造成系統(tǒng)高度不可用。為此，實際系統(tǒng)總是使用多個中心節(jié)點互為副本，成為一個小的集群，該小集群具有高可用性，對外提供頒發(fā)lease 的功能。chubby 和zookeeper 都是基于這樣的設計。

lease 的有效期時間選擇

工程中，常選擇的lease 時長是10 秒級別，這是一個經過驗證的經驗值，實踐中可以作為參考并綜合選擇合適的時長。

2.4 Quorum 機制

先做這樣的約定：更新操作(write)是一系列順序的過程，通過其他機制確定更新操作的順序(例如primary-secondary 架構中由primary 決定順序)，每個更新操作記為wi， i 為更新操作單調遞增的序號，每個wi 執(zhí)行成功后副本數(shù)據都發(fā)生變化，稱為不同的數(shù)據版本，記 作vi。假設每個副本都保存了歷史上所有版本的數(shù)據。

write-all-read-one

Write-all-read-one(簡稱WARO)是一種最簡單的副本控制規(guī)則，顧名思義即在更新時寫所有的副本，只有在所有的副本上更新成功，才認為更新成功，從而保證所有的副本一致，這樣在讀取數(shù)據時可以讀任一副本上的數(shù)據。

由于更新操作需要在所有的N 個副本上都成功，更新操作才能成 功，所以一旦有一個副本異常，更新操作失敗，更新服務不可用。對于更新服務，雖然有N 個副本， 但系統(tǒng)無法容忍任何一個副本異常。另一方面，N 個副本中只要有一個副本正常，系統(tǒng)就可以提供讀服務。對于讀服務而言，當有N 個副本時，系統(tǒng)可以容忍N-1 個副本異常。從上述分析可以發(fā)現(xiàn)WARO 讀服務的可用性較高，但更新服務的可用性不高，甚至雖然使用了副本，但更新服務的可用性等效于沒有副本。

Quorum 定義

在Quorum 機制下，當某次更新操作wi 一旦在所有N 個副本中的W 個副本上都成功，則就稱 該更新操作為“成功提交的更新操作”，稱對應的數(shù)據為“成功提交的數(shù)據”。令R>N-W，由于更新 操作wi 僅在W 個副本上成功，所以在讀取數(shù)據時，最多需要讀取R 個副本則一定能讀到wi 更新后 的數(shù)據vi 。如果某次更新wi 在W 個副本上成功，由于W+R>N，任意R 個副本組成的集合一定與 成功的W個副本組成的集合有交集，所以讀取R 個副本一定能讀到wi 更新后的數(shù)據vi。

如圖 2-10， Quorum 機制的原理可以文森圖表示。

某系統(tǒng)有5 個副本，W=3，R=3，最初5 個副本的數(shù)據一致，都是v1，某次更新操作 w2 在前3 副本上成功，副本情況變成(v2 v2 v2 v1 v1)。

此時，任意3 個副本組成的集合中一定包括 v2。在上述定義中，令W=N，R=1，就得到WARO，即WARO 是Quorum 機制的一種特例。與分析WARO 相似，分析Quorum 機制的可用性。限制Quorum 參數(shù)為W+R=N+1。由于更新 操作需要在W 個副本上都成功，更新操作才能成功，所以一旦N-W+1 個副本異常，更新操作始終無法在W 個副本上成功，更新服務不可用。

另一方面，一旦N-R+1 個副本異常，則無法保證一定可以讀到與W 個副本有交集的副本集合，則讀服務的一致性下降。

再次強調：僅僅依賴quorum 機制是無法保證強一致性的。因為僅有quorum 機制時無法確定最新已成功提交的版本號，除非將最新已提交的版本號作為元數(shù)據由特定的元數(shù)據服務器或元數(shù)據集群管理，否則很難確定最新成功提交的版本號。在下一節(jié)中，將討論在哪些情況下，可以僅僅 通過quorum 機制來確定最新成功提交的版本號。

Quorum 機制的三個系統(tǒng)參數(shù)N、W、R 控制了系統(tǒng)的可用性，也是系統(tǒng)對用戶的服務承諾：數(shù)據最多有N 個副本，但數(shù)據更新成功W 個副本即返回用戶成功。對于一致性要求較高的Quorum 系統(tǒng)，系統(tǒng)還應該承諾任何時候不讀取未成功提交的數(shù)據，即讀取到的數(shù)據都是曾經在W 個副本上成功的數(shù)據。

讀取最新成功提交的數(shù)據

Quorum 機制只需成功更新N 個副本中的W 個，在讀取R 個副本時，一定可以讀到最新的成功提交的數(shù)據。但由于有不成功的更新情況存在，僅僅讀取R 個副本卻不一定能確定哪個版本的數(shù)據 是最新的已提交的數(shù)據。對于一個強一致性Quorum 系統(tǒng)，若存在個數(shù)據少于W 個，假設為X 個，則繼續(xù)讀取其他副本，直若成功讀取到W 個 該版本的副本，則該數(shù)據為最新的成功提交的數(shù)據;如果在所有副本中該數(shù)據的個數(shù)肯定不滿 足W 個，則R 中版本號第二大的為最新的成功提交的副本。

例：在讀取到(v2 v1 v1)時，繼續(xù)讀取剩余的副本，若讀到剩余兩個副本 為(v2 v2)則v2 是最新的已提交的副本;若讀到剩余的兩個副本為(v2 v1)或(v1 v1)則v1 是最新成功提交的版本;若讀取后續(xù)兩個副本有任一超時或失敗，則無法判斷哪個版本是最新的成功提交的版本。

可以看出，在單純使用Quorum 機制時，若要確定最新的成功提交的版本，最多需要讀取R+ (W-R-1)=N 個副本，當出現(xiàn)任一副本異常時，讀最新的成功提交的版本這一功能都有可能不可用。

實際工程中，應該盡量通過其他技術手段，回避通過Quorum 機制讀取最新的成功提交的版本。例如，當quorum 機制與primary-secondary 控制協(xié)議結合使用時，可以通過讀取primary 的方式讀取到最新的已提交的數(shù)據。

基于Quorum 機制選擇primary副本

讀取數(shù)據時依照一致性要求的不同可以有不同的做法：如果需要強一致性的立刻讀取到最新的成功提交的數(shù)據，則可以簡單的只讀取primary 副本上的數(shù)據即可，也可以通過上節(jié)的方式讀取;

如果需要會話一致性，則可以根據之前已經讀到的數(shù)據版本號在各個副本上進行選擇性讀取;如果只需要弱一致性，則可以選擇任意副本讀取。

在primary-secondary 協(xié)議中，當primary 異常時，需要選擇出一個新的primary，之后secondary 副本與primary 同步數(shù)據。

通常情況下，選擇新的primary 的工作是由某一中心節(jié)點完成的，在引入 quorum 機制后，常用的primary 選擇方式與讀取數(shù)據的方式類似，即中心節(jié)點讀取R 個副本，選擇 R 個副本中版本號最高的副本作為新的primary。新primary 與至少W 個副本完成數(shù)據同步后作為新的primary 提供讀寫服務。

首先，R 個副本中版本號最高的副本一定蘊含了最新的成功提交的數(shù)據。再者，雖然不能確定最高版本號的數(shù)是一個成功提交的數(shù)據，但新的primary 在隨后與secondary 同 步數(shù)據，使得該版本的副本個數(shù)達到W，從而使得該版本的數(shù)據成為成功提交的數(shù)據。

例：在N=5，W=3，R=3 的系統(tǒng)中，某時刻副本最大版本號為(v2 v2 v1 v1 v1)，此時v1 是系統(tǒng)的最新的成功提交的數(shù)據，v2 是一個處于中間狀態(tài)的未成功提交的數(shù)據。假設此刻原primary 副本異常，中心節(jié)點進行primary 切換工作。這類“中間態(tài)”數(shù)據究竟作為“臟數(shù)據”被刪除，還是作為新的數(shù)據被同步后成為生效的數(shù)據，完全取決于這個數(shù)據能否參與新primary 的選舉。下面分別分析這兩種情況。

第一、如圖 2-12，若中心節(jié)點與其中3 個副本通信成功，讀取到的版本號為(v1 v1 v1)，則任 選一個副本作為primary，新primary 以v1 作為最新的成功提交的版本并與其他副本同步，當與第1、第2 個副本同步數(shù)據時，由于第1、第2 個副本版本號大于primary，屬于臟數(shù)據，可以按照2.2.2.4 節(jié)中介紹的處理臟數(shù)據的方式解決。

實踐中，新primary 也有可能與后兩個副本完成同步后就提供數(shù)據服務，隨后自身版本號也更新到v2，如果系統(tǒng)不能保證之后的v2 與之前的v2 完全一樣，則新 primary 在與第1、2 個副本同步數(shù)據時不但要比較數(shù)據版本號還需要比較更新操作的具體內容是否一樣。

第二、若中心節(jié)點與其他3 個副本通信成功，讀取到的版本號為(v2 v1 v1)，則選取版本號為 v2 的副本作為新的primary，之后，一旦新primary 與其他2 個副本完成數(shù)據同步，則符合v2 的副 本個數(shù)達到W 個，成為最新的成功提交的副本，新primary 可以提供正常的讀寫服務。

2.5 日志技術

日志技術是宕機恢復的主要技術之一。日志技術最初使用在數(shù)據庫系統(tǒng)中。嚴格來說日志技術不是一種分布式系統(tǒng)的技術，但在分布式系統(tǒng)的實踐中，卻廣泛使用了日志技術做宕機恢復，甚 至如BigTable 等系統(tǒng)將日志保存到一個分布式系統(tǒng)中進一步增強了系統(tǒng)容錯能力。

Redo Log 與Check point

設計一個高速的單機查詢系統(tǒng)，將數(shù)據全部存放在內存中以實現(xiàn)高速的數(shù)據查詢，每次更新操作更新一小部分數(shù)據(例如 key-value 中的某一個key)?，F(xiàn)在問題為利用日志技術實現(xiàn)該內存查詢系統(tǒng)的宕機恢復。與數(shù)據庫的事務不同的是，這個問題模型中的每個成功的更新操作都會生效。這也等效為數(shù)據庫的每個事務只有一個更新操作，且每次更新操作都可以也必須立即提交(Auto commit)。

• Redo Log

將更新操作的結果(例如Set K1=1，則記錄K1=1)以追加寫(append)的方式寫入磁盤的 日志文件

按更新操作修改內存中的數(shù)據

返回更新成功

從Redo Log 的流程可以看出，Redo 寫入日志的是更新操作完成后的結果(雖然本文不討論Undo Log，這點是與Undo Log 的區(qū)別之一)，且由于是順序追加寫日志文件，在磁盤等對順序寫有力的 存儲設備上效率較高。

用Redo Log 進行宕機恢復非常簡單，只需要“回放”日志即可。

流程2.5.2：Redo Log 的宕機恢復

從頭讀取日志文件中的每次更新操作的結果，用這些結果修改內存中的數(shù)據。

從Redo Log 的宕機恢復流程也可以看出，只有寫入日志文件的更新結果才能在宕機后恢復。這也是為什么在Redo Log 流程中需要先更新日志文件再更新內存中的數(shù)據的原因。

假如先更新內存中的數(shù)據，那么用戶立刻就能讀到更新后的數(shù)據，一旦在完成內存修改與寫入日志之間發(fā)生宕機，那么最后一次更新操作無法恢復，但之前用戶可能已經讀取到了更新后的數(shù)據，從而引起不一致的問題。

• Check point

在簡化的模型下，check point 技術的過程即將內存中的數(shù)據以某種易于重新加載的數(shù)據組織方式完整的dump 到磁盤，從而減少宕機恢復時需要回放的日志數(shù)據。

流程：check point

1. 向日志文件中記錄“Begin Check Point”
2. 將內存中的數(shù)據以某種易于重新加載的數(shù)據組織方式dump 到磁盤上
3. 向日志文件中記錄“End Check Point” 在check point 流程中，數(shù)據可以繼續(xù)按照流程2.5.1 被更新，這段過程中新更新的數(shù)據可以dump 到磁盤也可以不dump 到磁盤，具體取決于實現(xiàn)。例如，check point 開始時k1=v1，check point 過程 中某次更新為k1 = v2，那么dump 到磁盤上的k1 的值可以是v1 也可以是v2。

流程：基于check point 的宕機恢復流程

將dump 到磁盤的數(shù)據加載到內存。

從后向前掃描日志文件，尋找最后一個“End Check Point”日志。

從最后一個“End Check Point”日志向前找到最近的一個“Begin Check Point”日志，并回 放該日志之后的所有更新操作日志。

No Undo/No Redo log

若數(shù)據維護在磁盤中，某批更新由若干個更新操作組成，這些更新操作需要原子生效，即要么同時生效，要么都不生效。

0/1 目錄技術中有兩個目錄結構，稱為目錄0(Directory 0)和目錄1(Directory 1)。另有一個結構稱為主記錄(Master record)記錄當前正在使用的目錄稱為活動目錄。主記錄中要么記錄使用目錄0，要么記錄使用目錄1。目錄0 或目錄1 中記錄了各個數(shù)據的在日志文件中的位置。0/1 目錄的數(shù)據更新過程始終在非活動目錄上進行，只是在數(shù)據生效前，將主記錄中的0、1 值反轉，從而切換主記錄。

流程：0/1 目錄數(shù)據更新流程

1. 將活動目錄完整拷貝到非活動目錄。
2. 對于每個更新操作，新建一個日志項紀錄操作后的值，并在非活動目錄中將相應數(shù)據的位置修改為新建的日志項的位置。
3. 原子性修改主記錄：反轉主記錄中的值，使得非活動目錄生效。

0/1 目錄的更新流程非常簡單，通過0、1 目錄的主記錄切換使得一批修改的生效是原子的。0/1 目錄將批量事務操作的原子性通過目錄手段歸結到主記錄的原子切換。

由于多條記錄的原子修改一般較難實現(xiàn)而單條記錄的原子修改往往可以實現(xiàn)，從而降低了問題實現(xiàn)的難度。

在工程中0/1 目錄的思想運用非常廣泛，其形式也不局限在上述流程中，可以是內存中的兩個數(shù)據結構來回切換，也可以是磁盤上的兩個文件目錄來回生效切換。

2.6 兩階段提交協(xié)議

兩階段提交協(xié)議是一種經典的強一致性中心化副本控制協(xié)議。雖然在工程中該協(xié)議有較多的問題，但研究該協(xié)議能很好的理解分布式系統(tǒng)的幾個典型問題。

流程描述

兩階段提交協(xié)議是一種典型的“中心化副本控制”協(xié)議。在該協(xié)議中，參與的節(jié)點分為兩類：一個中心化協(xié)調者節(jié)點(coordinator)和N 個參與者節(jié)點(participant)。每個參與者節(jié)點即上文背景介紹中的管理數(shù)據庫副本的節(jié)點。

兩階段提交的思路比較簡單，在第一階段，協(xié)調者詢問所有的參與者是否可以提交事務(請參與者投票)，所有參與者向協(xié)調者投票。

在第二階段，協(xié)調者根據所有參與者的投票結果做出是否事務可以全局提交的決定，并通知所有的參與者執(zhí)行該決定。在一個兩階段提交流程中，參與者不能改變自己的投票結果。

兩階段提交協(xié)議的可以全局提交的前提是所有的參與者都同意提交事務，只要有一個參與者投票選擇放棄(abort)事務，則事務必須被放棄。

流程：兩階段提交協(xié)調者流程

1. 寫本地日志“begin_commit”，并進入WAIT 狀態(tài);
2. 向所有參與者發(fā)送“prepare 消息”;
3. 等待并接收參與者發(fā)送的對“prepare 消息”的響應;3.1 若收到任何一個參與者發(fā)送的“vote-abort 消息”;3.1.1 寫本地“global-abort”日志，進入ABORT;3.1.2 向所有的參與者發(fā)送“global-abort 消息”;3.1.3 進入ABORT 狀態(tài);3.2 若收到所有參與者發(fā)送的“vote-commit”消息;3.2.1 寫本地“global-commit”日志，進入COMMIT 狀態(tài);3.1.2 向所有的參與者發(fā)送“global-commit 消息”;
4. 等待并接收參與者發(fā)送的對“global-abort 消息”或“global-commit 消息”的確認響應消息，一旦收到所有參與者的確認消息，寫本地“end_transaction” 日志流程結束。

流程：兩階段提交協(xié)調者流程

1. 寫本地日志“init”記錄，進入INIT 狀態(tài)
2. 等待并接受協(xié)調者發(fā)送的“prepare 消息”，收到后 2.1 若參與者可以提交本次事務 2.1.1 寫本地日志“ready”，進入READY 狀態(tài) 2.1.2 向協(xié)調者發(fā)送“vote-commit”消息 2.1.4 等待協(xié)調者的消息2.1.4.1 若收到協(xié)調者的“global-abort”消息2.1.4.1.1 寫本地日志“abort”，進入ABORT 狀態(tài)2.1.4.1.2 向協(xié)調者發(fā)送對“global-abort”的確認消息 2.1.4.2 若收到協(xié)調者的“global-commit”消息2.1.4.1.1 寫本地日志“commit”，進入COMMIT 狀態(tài) 2.1.4.1.2 向協(xié)調者發(fā)送對“global-commit”的確認消息 2.2 若參與者無法提交本次事務 2.2.1 寫本地日志“abort”，進入ABORT 狀態(tài) 2.2.2 向協(xié)調者發(fā)送“vote-abort”消息 2.2.3 流程對該參與者結束 2.2.4 若后續(xù)收到協(xié)調者的“global-abort”消息可以響應
3. 即使流程結束，但任何時候收到協(xié)調者發(fā)送的“global-abort”消息或“global-commit”消息也都要發(fā)送一個對應的確認消息。

異常處理

宕機恢復

1. 協(xié)調者宕機恢復 協(xié)調者宕機恢復后，首先通過日志查找到宕機前的狀態(tài)。如果日志中最后是“begin_commit”記錄，說明宕機前協(xié)調者處于WAIT 狀態(tài)，協(xié)調者可能已經發(fā)送過“prepare 消息”也可能還沒發(fā)送，但協(xié)調者一定還沒有發(fā)送過“global-commit 消息”或“global-abort 消息”，即事務的全局狀態(tài)還沒有確定。此時，協(xié)調者可以重新發(fā)送“prepare 消息” 繼續(xù)兩階段提交流程，即使參與者已經發(fā)送過對“prepare 消息”的響應，也不過是再次重傳之前的響應而不會影響協(xié)議的一致性。如果日志中最后是“global-commit”或“global-abort”記錄，說明宕機前協(xié)調者處于COMMIT 或ABORT 狀態(tài)。此時協(xié)調者只需重新向所有的參與者發(fā)送“global-commit 消息”或“global-abort 消息”就可以繼續(xù)兩階段提交流程。
2. 參與者宕機恢復參與者宕機恢復后，首先通過日志查找宕機前的狀態(tài)。如果日志中最后是“init”記錄，說明參與者處于INIT 狀態(tài)，還沒有對本次事務做出投票選擇，參與者可以繼續(xù)流程等待協(xié)調者發(fā)送的“prepare 消息”。如果日志中最后是“ready”記錄，說明參與者處于REDAY 狀態(tài)，此時說明參與者已經就本次 事務做出了投票選擇，但宕機前參與者是否已經向協(xié)調者發(fā)送“vote-commit”消息并不可知。所以此時參與者可以向協(xié)調者重發(fā)“vote-commit”，并繼續(xù)協(xié)議流程。如果日志中最后是“commit”或“abort”記錄，說明參與者已經收到過協(xié)調者的“global-commit 消息”(處于COMMIT 狀態(tài))或者“global-abort 消息”(處于ABORT 狀態(tài))。至于是否向協(xié)調者發(fā) 送過對“global-commit”或“global-abort”的確認消息則未知。但即使沒有發(fā)送過確認消息，由于協(xié)調者會不斷重發(fā)“global-commit”或“global-abort”，只需在收到這些消息時發(fā)送確認消息既可，不影響協(xié)議的全局一致性。

協(xié)議分析

兩階段提交協(xié)議在工程實踐中真正使用的較少，主要原因有以下幾點：

1. 兩階段提交協(xié)議的容錯能力較差。從上文的分析可以看出，兩階段提交協(xié)議在某些情況下存在流程無法執(zhí)行下去的情況，且也無法判斷流程狀態(tài)。在工程中好的分布式協(xié)議往往總是可以在即使發(fā)生異常的情況下也能執(zhí)行下去。例如，回憶Lease 機制(2.3 )，一旦lease 發(fā)出，無論出現(xiàn)任何異常，Lease 服務器節(jié)點總是可以通過時間判定出Lease 是否有效，也可以用等待Lease 超時的方法收回Lease 權限，整個Lease 協(xié)議的流程不存在任何流程被阻塞而無法執(zhí)行下去的情況。與Lease 機制的簡單有效相比，兩階段提交的協(xié)議顯得較為復雜且容錯能力差。
2. 兩階段提交協(xié)議的性能較差。一次成功的兩階段提交協(xié)議流程中，協(xié)調者與每個參與者 之間至少需要兩輪交互4 個消息“prepare”、“vote-commit”、“global-commit”、“確認global-commit”。過多的交互次數(shù)會降低性能。另一方面，協(xié)調者需要等待所有的參與者的投票結果，一旦存在較慢的參與者，會影響全局流程執(zhí)行速度。

雖然存在一些改進的兩階段提交協(xié)議可以提高容錯能力和性能，然而這類協(xié)議依舊是在工程中使用較少的一類協(xié)議，其理論價值大于實踐意義。

2.7 MVCC

MVCC(Multi-version Cocurrent Control，多版本并發(fā)控制)技術。MVCC 技術最初也是在數(shù)據庫系統(tǒng)中被提出，但這種思想并不局限于單機的分布式系統(tǒng)，在分布式系統(tǒng)中同樣有效。

MVCC 即多個不同版本的數(shù)據實現(xiàn)并發(fā)控制的技術，其基本思想是為每次事務生成 一個新版本的數(shù)據，在讀數(shù)據時選擇不同版本的數(shù)據即可以實現(xiàn)對事務結果的完整性讀取。在使用MVCC 時，每個事務都是基于一個已生效的基礎版本進行更新，事務可以并行進行，從而可以產生一種圖狀結構。

基礎數(shù)據的版本為1，同時產生了兩個事務：事務A 與事務B。這兩個事務都各自對數(shù)據進行了一些本地修改(這些修改只有事務自己可見，不影響真正的數(shù)據)，之后事務A 首先提交，生成數(shù)據版本2;基于數(shù)據版本2，又發(fā)起了事務C，事務C 繼續(xù)提交，生成了數(shù)據版 本3;最后事務B 提交，此時事務B 的結果需要與事務C 的結果合并，如果數(shù)據沒有沖突，即事務 B 沒有修改事務A 與事務C 修改過的變量，那么事務B 可以提交，否則事務B 提交失敗。MVCC 的流程過程非常類似于SVN 等版本控制系統(tǒng)的流程，或者說SVN 等版本控制系統(tǒng)就是 使用的MVCC 思想。事務在基于基礎數(shù)據版本做本地修改時，為了不影響真正的數(shù)據，通常有兩種做法，一是將基礎數(shù)據版本中的數(shù)據完全拷貝出來再修改，SVN 即使用了這種方法，SVN check out 即是拷貝的過程;二是每個事務中只記錄更新操作，而不記錄完整的數(shù)據，讀取數(shù)據時再將更新操作應用到用基礎版本的數(shù)據從而計算出結果，這個過程也類似SVN 的增量提交。

2.8 Paxos協(xié)議

Paxos 協(xié)議是少數(shù)在工程實踐中證實的強一致性、高可用的去中心化分布式協(xié)議。Paxos 協(xié)議的流程較為復雜，但其基本思想卻不難理解，類似于人類社會的投票過程。Paxos 協(xié)議中，有一組完全對等的參與節(jié)點(稱為accpetor)，這組節(jié)點各自就某一事件做出決議，如果某個決議獲得了超過半數(shù)節(jié)點的同意則生效。Paxos 協(xié)議中只要有超過一半的節(jié)點正常，就可以工作，能很好對抗宕機、網絡分化等異常情況。

角色

Proposer：提案者。Proposer 可以有多個，Proposer 提出議案(value)。所謂value，在工程中可以是任何操作，例如“修改某個變量的值為某個值”、“設置當前primary 為某個節(jié)點”等等。Paxos 協(xié)議中統(tǒng)一將這些操作抽象為value。不同的Proposer 可以提出不同的甚至矛盾的value，例如某個Proposer 提議“將變量X 設置為1”，另一個Proposer 提議“將變量X 設置為2”，但對同一輪Paxos 過程，最多只有一個value 被批準。Acceptor：批準者。Acceptor 有N 個，Proposer 提出的value 必須獲得超過半數(shù)(N/2+1)的Acceptor 批準后才能通過。Acceptor 之間完全對等獨立。Learner：學習者。Learner 學習被批準的value。所謂學習就是通過讀取各個Proposer 對value 的選擇結果，如果某個value 被超過半數(shù)Proposer 通過，則Learner 學習到了這個value。回憶(2.4 ) 不難理解，這里類似Quorum 機制，某個value 需要獲得W=N/2 + 1 的Acceptor 批準，從而學習者需要至少讀取N/2+1 個Accpetor，至多讀取N 個Acceptor 的結果后，能學習到一個通過的value。上述三類角色只是邏輯上的劃分，實踐中一個節(jié)點可以同時充當這三類角色。

流程

Paxos 協(xié)議一輪一輪的進行，每輪都有一個編號。每輪Paxos 協(xié)議可能會批準一個value，也可 能無法批準一個value。如果某一輪Paxos 協(xié)議批準了某個value，則以后各輪Paxos 只能批準這個 value。上述各輪協(xié)議流程組成了一個Paxos 協(xié)議實例，即一次Paxos 協(xié)議實例只能批準一個value，這也是Paxos 協(xié)議強一致性的重要體現(xiàn)。每輪Paxos 協(xié)議分為階段，準備階段和批準階段，在這兩個階段Proposer 和Acceptor 有各自的處理流程。

流程：Proposer 的流程 (準備階段)

1. 向所有的Acceptor 發(fā)送消息“Prepare(b)”;這里b 是Paxos 的輪數(shù)，每輪遞增
2. 如果收到任何一個Acceptor 發(fā)送的消息“Reject(B)”，則對于這個Proposer 而言本輪Paxos 失敗，將輪數(shù)b 設置為B+1 后重新步驟1;(批準階段，根據收到的Acceptor 的消息作出不同選擇)
3. 如果接收到的Acceptor 的“Promise(b, v_i)”消息達到N/2+1 個(N 為Acceptor 總數(shù)，除法取整， 下同);v_i 表示Acceptor 最近一次在i 輪批準過value v。3.1 如果收到的“Promise(b, v)”消息中，v 都為空，Proposer 選擇一個value v，向所有Acceptor 廣播Accept(b, v);3.2 否則，在所有收到的“Promise(b, v_i)”消息中，選擇i 最大的value v，向所有Acceptor 廣播消息Accept(b，v);
4. 如果收到Nack(B)，將輪數(shù)b 設置為B+1 后重新步驟1;

流程：Accpetor 流程 (準備階段)

接受某個Propeser 的消息Prepare(b)。參數(shù)B 是該Acceptor 收到的最大Paxos 輪數(shù)編號;V 是Acceptor 批準的value，可以為空 1.1 如果b>B，回復Promise(b, V_B)，設置B=b; 表示保證不再接受編號小于b 的提案。1.2 否則，回復Reject(B) (批準階段)

接收Accept(b, v)， 2.1 如果b < B, 回復Nack(B)，暗示proposer 有一個更大編號的提案被這個Acceptor 接收了 2.2 否則設置V=v。表示這個Acceptor 批準的Value 是v。廣播Accepted 消息。

例子

基本例子里有5 個Acceptor，1 個Proposer，不存在任何網絡、宕機異常。我們著重考察各個Accpetor 上變量B 和變量V 的變化，及Proposer 上變量b 的變化。

1. 初始狀態(tài)
2. Proposer 向所有Accpetor 發(fā)送“Prepare(1)”，所有Acceptor 正確處理，并回復Promise(1, NULL
3. Proposer 收到5 個Promise(1, NULL)，滿足多余半數(shù)的Promise 的value 為空，此時發(fā)送 Accept(1, v1)，其中v1 是Proposer 選擇的Value。
4. 此時，v1 被超過半數(shù)的Acceptor 批準，v1 即是本次Paxos 協(xié)議實例批準的Value。如果Learner 學習value，學到的只能是v1

在同一個Paxos 實例中，批準的Value 是無法改變的，即使后續(xù)Proposer 以更高的序號發(fā)起Paxos 協(xié)議也無法改變value。Paxos 協(xié)議的核心就在于“批準的value 無法改變”，這也是整個協(xié)議正確性的基礎。

Paxos 協(xié)議是被人為設計出來，其設計過程也是協(xié)議的推導過程。Paxos 協(xié)議利用了Quorom 機 制，選擇的W=R=N/2+1。

簡單而言，協(xié)議就是Proposer 更新Acceptor 的過程，一旦某個Acceptor 成功更新了超過半數(shù)的Acceptor，則更新成功。Learner 按Quorum 去讀取Acceptor，一旦某個value 在超過半數(shù)的Proposer 上被成功讀取，則說明這是一個被批準的value。協(xié)議通過引入輪次，使得高輪次的提議搶占低輪次的提議來避免死鎖。協(xié)議設計關鍵點是如何滿足“在一次Paxos 算法實例過程中只批準一個Value”這
網頁標題：聊一聊分布式系統(tǒng)原理
文章網址：http://m.fisionsoft.com.cn/article/dposdjo.html