我們每天都在講分布式和分布式，那么我們知道什么是分布式，分布式會遇到什么問題，有哪些理論支持，有哪些經(jīng)典方案，行業(yè)如何設(shè)計和保證分布式的高可用？系統(tǒng)？

1.建筑設(shè)計

本節(jié)將從一些經(jīng)典的開源系統(tǒng)架構(gòu)設(shè)計開始，看看如何設(shè)計一個高質(zhì)量的分布式系統(tǒng)；

一般的設(shè)計出發(fā)點無非就是

1.1 主備架構(gòu)

為現(xiàn)有服務(wù)構(gòu)建備份服務(wù)。兩者的功能完全相同。不同的是，通常只有主應(yīng)用提供外部服務(wù)能力；而備用應(yīng)用只需要保證主應(yīng)用的能力與主應(yīng)用的能力一致即可。服務(wù); 當(dāng)主應(yīng)用出現(xiàn)故障時，備用應(yīng)用切換為主應(yīng)用，原主應(yīng)用下線；快速主備切換，有效縮短故障時間

綜上所述，主備架構(gòu)的特點就比較清楚了。

其次，在這個架構(gòu)模型中最需要考慮的是如何實現(xiàn)主備切換？

1.2 主從架構(gòu)

主從一般稱為讀寫分離。 提供讀寫能力， 只提供讀寫能力。

從目前的互聯(lián)網(wǎng)應(yīng)用來看，大多是讀多寫少的場景；讀更容易成為性能瓶頸，所以使用讀寫分離可以有效提升整個集群的響應(yīng)能力

主從架構(gòu)可以分為：一主、多從+一主、一從、多從。以主從架構(gòu)模型為例進行說明

主從模式的主要特點是

關(guān)鍵問題是

1.3 多主多從架構(gòu)

一主多從面對單主節(jié)點的瓶頸，再考慮多主多從的策略。也負責(zé)提供read和，提供read；

但是這里有一個核心點就是多個之間的數(shù)據(jù)同步，如何保證數(shù)據(jù)的一致性是這個架構(gòu)模型的重點

比如雙主雙從可以說是一個典型的應(yīng)用場景。除了以上的一致性，實際使用中還需要考慮主鍵id沖突的問題。

1.4 普通集群模式

沒有主節(jié)點，集群中所有應(yīng)用功能都是平等的，沒有主次之分（目前大部分業(yè)務(wù)服務(wù)都屬于這一類），一個請求可以被集群中的任何一個服務(wù)響應(yīng)；

這也可以稱為去中心化設(shè)計模式，如集群模式、注冊中心，以可用性為首要目標(biāo)

對于普通集群模式，要考慮的關(guān)鍵點是

數(shù)據(jù)一致性：如何保證所有實例數(shù)據(jù)一致，或者最終一致

1.5 數(shù)據(jù)分片架構(gòu)

此分片模型的描述可能不準(zhǔn)確。當(dāng)你閱讀它時，專注于理解這個想法。

在之前的架構(gòu)中，都是采用數(shù)據(jù)冗余的方式，即所有實例都有全量數(shù)據(jù)，而這里的數(shù)據(jù)分片是從數(shù)據(jù)拆分的思想來處理的，全量數(shù)據(jù)通過。將一定的規(guī)則劃分為多個系統(tǒng)，每個系統(tǒng)包含部分?jǐn)?shù)據(jù)，減少單個節(jié)點的壓力，主要用于解決數(shù)據(jù)量大的場景

例如，在集群模式下，分區(qū)是由散列槽執(zhí)行的。

es等索引分片存儲

1.6 灰色總結(jié)

本節(jié)主要從架構(gòu)設(shè)計層面對當(dāng)前分布式系統(tǒng)解決方案進行簡單的分類和總結(jié)，不一定全面。歡迎留言指正

基于冗余的思想：

分裂思維：

對于分割這塊，我們常說的分庫分表也體現(xiàn)了這個思想

2.理論基礎(chǔ)

本節(jié)將介紹分布式系統(tǒng)中的經(jīng)典理論，如廣義過程的CAP/BASE理論、一致性理論基礎(chǔ)、raft、信息交換協(xié)議、兩階段、三階段等。

本節(jié)主要內(nèi)容指

2.1 CAP 定理

CAP 定理指出，分布式系統(tǒng)不可能同時提供以下三個要求：

： 可用性

: 分區(qū)容錯

一般來說，很難不保證P。當(dāng)服務(wù)部署在多個實例上時，節(jié)點異常和網(wǎng)絡(luò)故障是正常的，根據(jù)不同的業(yè)務(wù)場景進行選擇。

對于服務(wù)有限的應(yīng)用，AP是保證高可用的首選。即使部分機器出現(xiàn)異常，也不會導(dǎo)致整個服務(wù)不可用；例如，大多數(shù)前臺應(yīng)用程序是這樣的

對于數(shù)據(jù)一致性要求高的場景，比如涉及錢的支付結(jié)算，CP可能更重要

CAP的三種組合描述如下

2.2 基礎(chǔ)理論

作為上限的延伸，基礎(chǔ)理論的核心特征是摒棄強一致性，追求最終一致性

軟：軟狀態(tài)

: 最終一致性

綜合以上描述可以看出，BASE理論適用于大規(guī)模高可用、可擴展的分布式系統(tǒng)

注意，它不同于 ACID 的強一致性模型，而是通過犧牲強一致性來獲得可用性，并允許數(shù)據(jù)在一段時間內(nèi)不一致，但最終達到一致狀態(tài)

2.3 定理

沒聽說過，以下來自：

定理的第一部分（PAC）與CAP定理相同，ELC是一個擴展。整個論點假設(shè)我們通過復(fù)制保持高可用性。因此，當(dāng)它失敗時，CAP 定理占上風(fēng)。但如果不是，我們?nèi)匀恍枰紤]復(fù)制系統(tǒng)中一致性和延遲之間的權(quán)衡。

2.4 共識算法

該算法解決的問題是分布式共識問題，即分布式系統(tǒng)中的各個進程如何通過共識就某個值（分辨率）達成一致

根據(jù)上面的描述，可以看出非常適合選舉；它的工作流程

角色劃分：

：不參與決策一致性hash算法php開源，獲取最新提案

2.5 Raft 算法

推薦感興趣的朋友，查看

為了解決復(fù)雜度，raft算法提供了一個更易理解的算法基礎(chǔ)，其核心流程為：

接受請求并轉(zhuǎn)發(fā)到，當(dāng)收到大部分響應(yīng)時，通知所有提交請求，自己提交請求并告訴調(diào)用者 ok

角色劃分：

2.6 ZAB 協(xié)議

ZAB() 協(xié)議是專為分布式協(xié)調(diào)服務(wù)設(shè)計的支持崩潰恢復(fù)的一致性協(xié)議?；谠搮f(xié)議，實現(xiàn)了主從模式的系統(tǒng)架構(gòu)，以保持集群中副本之間的數(shù)據(jù)一致性。

主要用于zk的數(shù)據(jù)一致性場景。核心思想是收到交易請求后，通過給定，當(dāng)一半以上返回ACK時，提交提案并發(fā)送信息給

角色劃分

: 追隨者

: 是從 3.3.0 開始引入的一個角色，

2.7 2PC 協(xié)議

二、兩階段提交協(xié)議，主要解決強一致性，集中式強一致性協(xié)議

角色劃分

實施過程

協(xié)調(diào)者節(jié)點接收到請求，然后將其提交給參與者節(jié)點。當(dāng)所有參與者都回復(fù)ok后，協(xié)調(diào)節(jié)點提交給所有參與者節(jié)點，全部返回ok后，數(shù)據(jù)確認提交。

當(dāng)參與者在第一階段失敗時，所有參與者節(jié)點都回滾

特征

優(yōu)點是易于實現(xiàn)

缺點也很明顯

2.8 3PC 協(xié)議

分布式事務(wù)：兩階段提交與三階段提交

在兩階段展開的基礎(chǔ)上，第一階段分為兩部分，+，第三階段為

第一階段

在這個階段，協(xié)調(diào)者會詢問每個參與者是否可以正常執(zhí)行交易，參與者會根據(jù)自己的情況回復(fù)一個估計值。與真正的執(zhí)行交易相比，這個過程是輕量級的

第二階段

在這個階段，協(xié)調(diào)者會根據(jù)第一階段的查詢結(jié)果采取相應(yīng)的行動。如果所有參與者都返回ok，則協(xié)調(diào)者將向參與者提交事務(wù)執(zhí)行（單個未提交）通知；否則，將通知參與者回滾

第三階段

如果第二階段的事務(wù)沒有中斷，這個階段的協(xié)調(diào)者會根據(jù)事務(wù)執(zhí)行返回的結(jié)果來決定提交或回滾事務(wù)。如果所有參與者都正常執(zhí)行，他們將提交；否則，協(xié)調(diào)者 + 參與者將回滾

在這個階段一致性hash算法php開源，如果參與者因為協(xié)調(diào)者或網(wǎng)絡(luò)問題而未能收到協(xié)調(diào)者的 OR 請求，參與者不會像兩階段提交那樣被阻塞，而是會等待超時繼續(xù)進行，相比于兩階段提交- 減少同步阻塞，但仍不能完全避免數(shù)據(jù)不一致

特征

數(shù)據(jù)不一致依然存在

2.9 協(xié)議

該協(xié)議，顧名思義，就像八卦一樣，采用一種隨機且具有傳染性的方式在整個網(wǎng)絡(luò)中傳播信息，并使系統(tǒng)中的所有節(jié)點在一定時間內(nèi)保持一致。通過以上特性，協(xié)議可以保證系統(tǒng)在極端情況下也能運行（例如集群中只有一個節(jié)點在運行）

主要用于分布式數(shù)據(jù)庫系統(tǒng)中各個副本節(jié)點同步數(shù)據(jù)。這種場景的最大特點之一是形成的網(wǎng)絡(luò)的節(jié)點都是對等節(jié)點，是一個非結(jié)構(gòu)化的網(wǎng)絡(luò)。

工作過程

特征

缺點

2.10 灰色摘要

本節(jié)主要介紹分布式系統(tǒng)設(shè)計中一些常見的理論基石，例如如何保證分布式系統(tǒng)的一致性以及如何就一個提案達成共識

3.算法

本節(jié)將主要介紹分布式系統(tǒng)中的經(jīng)典算法，如分區(qū)常用的一致性哈希算法、適合一致性的NWR算法、PBFT拜占庭容錯算法、區(qū)塊鏈中廣泛使用的PoW等。算法等

3.1 一致性哈希算法

一致性哈希算法，主要用于數(shù)據(jù)分片場景，有效降低增刪服務(wù)對數(shù)據(jù)復(fù)制的影響

通過對數(shù)據(jù)項的鍵進行散列來映射其在環(huán)上的位置，然后順時針遍歷環(huán)，找到位置大于項的位置的第一個節(jié)點，將鍵標(biāo)識的每個數(shù)據(jù)分配給散列環(huán)一個節(jié)點

一致性哈希的主要優(yōu)點是增量穩(wěn)定性；節(jié)點的增刪，對于整個集群，只影響其近鄰，其他節(jié)點不受影響。

注意：

3.2 NWR 算法

用于確保數(shù)據(jù)冗余和最終一致性的投票算法的主要數(shù)學(xué)思想來自鴿巢原理

NWR算法要求每個數(shù)據(jù)拷貝對象可以投1票，每次操作的執(zhí)行需要獲得最少的讀票和寫票；一般來說網(wǎng)站開發(fā)，寫入票數(shù)W一般需要超過N/2，也就是我們通常說的get超過一半的票數(shù)說明數(shù)據(jù)寫入成功

實際上，當(dāng) W=N 且 R=1 時，稱為 WARO（All Read One）。這就是CAP理論中CP模型的場景。

3.3 PBFT拜占庭算法

拜占庭算法主要針對分布式場景下無響應(yīng)，或者響應(yīng)不可信時的容錯問題。其核心分為三個階段，如下

假設(shè)集群節(jié)點數(shù)為N，f個故障節(jié)點（無響應(yīng)）和f個問題節(jié)點（無響應(yīng)或錯誤響應(yīng)），f+1個正常節(jié)點，即3f+1=n

與完全不適合有人作惡的場景的 Raft 算法相比，PBFT 算法可以容忍（n 1)/3 個惡意節(jié)點（也可以是故障節(jié)點）。另外，與PoW算法，PBFT的優(yōu)點是不消耗算力，PBFT算法是O(n^2)的消息復(fù)雜度算法，所以隨著消息數(shù)量的增加，網(wǎng)絡(luò)延遲會有更大對系統(tǒng)運行的影響，限制了PBFT算法的運行，分布式系統(tǒng)的規(guī)模也決定了PBFT算法適用于中小型分布式系統(tǒng)

3.4 PoW算法

工作量證明（Of Work，簡稱PoW）也用于分布式一致性場景。它不同于之前的raft和pbft。它采用投票機制來達成共識方案。PoW 使用工作證明。

客戶端需要做一些困難的工作才能得到一個結(jié)果，但驗證者可以通過結(jié)果輕松檢查客戶端是否做了相應(yīng)的工作。通過消耗一定的工作量，增加了消息偽造的成本。廣泛應(yīng)用于鏈條，廣為人知。下面簡單說一下PoW算法與區(qū)塊鏈的應(yīng)用場景。

以轉(zhuǎn)BTC為例，A轉(zhuǎn)n個BTC給B，如何保證n個幣不會同時轉(zhuǎn)給C？

PoW算法主要用于上述區(qū)塊提交的驗證，通過哈希值計算消耗算力來證明礦工確實付出了，在多數(shù)同意的情況下才能達成共識。

3.5 灰色總結(jié)

本節(jié)主要介紹當(dāng)前分布式下的常用算法，

4.技術(shù)思路

與前面的內(nèi)容相比，本節(jié)的內(nèi)容不容易分類清楚；主要包括一些優(yōu)質(zhì)分布式系統(tǒng)實踐中推薦的設(shè)計思路和技術(shù)細節(jié)

4.1 個 CQRS

也就是我們通俗理解的讀寫分離，核心思想是將兩種不同的操作分開，在獨立的服務(wù)中實現(xiàn)

目的是將領(lǐng)域模型與查詢功能分離，讓一些復(fù)雜的查詢擺脫領(lǐng)域模型的限制，以更簡單的DTO形式顯示查詢結(jié)果。同時，不同的數(shù)據(jù)存儲結(jié)構(gòu)分離，讓開發(fā)者可以根據(jù)查詢的功能和需求更自由地選擇數(shù)據(jù)存儲引擎

4.2 復(fù)制負載均衡服務(wù)

復(fù)制負載均衡服務(wù)（Load，RLBS）可以簡單理解為我們常說的負載均衡。多個相同的服務(wù)實例構(gòu)建一個集群，每個服務(wù)可以響應(yīng)請求，負載均衡器負責(zé)將請求分發(fā)到不同的實例。上，常見的加載算法

4.3 心跳機制

分布式環(huán)境下，如何判斷一個服務(wù)是否存活，目前最常見的解決方案就是心跳

比如在raft算法中，向all發(fā)送心跳意味著你還活著，避免了新的選舉；

比如哨兵機制也是利用ping/pong的心跳來判斷節(jié)點是否下線，是否需要選擇新的主節(jié)點；

再比如我們?nèi)粘I(yè)務(wù)應(yīng)用的健康監(jiān)測，判斷服務(wù)是否正常

4.4 租賃機制

租約就像一把鎖，但即使客戶離開它也能工作。客戶端請求一個有限期限的租約，之后租約到期。如果客戶端想要延長租約，它可以在租約到期之前更新租約。

租約主要是為了避免一個資源被某個對象長期持有，一旦對方掛掉，就不會主動釋放的問題；在實際場景中，有兩種典型應(yīng)用

分布式鎖

業(yè)務(wù)獲取的分布式鎖一般都有有效期。如果在有效期內(nèi)沒有主動釋放，鎖依然會被釋放，其他業(yè)務(wù)也可以搶占鎖；因此，對于持有鎖的業(yè)務(wù)方，如果發(fā)現(xiàn)在到期之前，如果業(yè)務(wù)邏輯還沒有處理完，可以續(xù)約，讓自己繼續(xù)持有鎖

一個典型的實現(xiàn)是看門狗機制

raft算法的任期

在 raft 算法中，每個人都有一個任期，之后會被重新選舉。為了避免連任，一般會定期發(fā)送心跳來續(xù)約。

4.5 &

這個很容易理解，上面很多系統(tǒng)都采用了這種方案，尤其是在共識算法中，負責(zé)代表整個集群做出決策，并將決策傳播到所有其他服務(wù)器

領(lǐng)導(dǎo)者選舉發(fā)生在服務(wù)器啟動時。每臺服務(wù)器在啟動時都會發(fā)起一次領(lǐng)導(dǎo)選舉，并嘗試選舉一個領(lǐng)導(dǎo)。除非選舉出領(lǐng)導(dǎo)者，否則系統(tǒng)不接受任何客戶端請求

4.6

在-模型中，當(dāng)失效時，無法確定已經(jīng)停止工作，比如網(wǎng)絡(luò)慢或者網(wǎng)絡(luò)分區(qū)可能觸發(fā)新的選舉，即使之前的還在運行并且認為依然是賽事的領(lǐng)頭羊

指在先前活動的領(lǐng)導(dǎo)者周圍放置一個柵欄，使其無法訪問集群資源，從而阻止任何讀/寫請求被服務(wù)

4.7 法定人數(shù)

，常用于選舉和共識算法。當(dāng)超過的節(jié)點數(shù)被確認后，提案通過（數(shù)據(jù)更新成功）。通常，法定人數(shù)是=一半的節(jié)點+1

4.8 高分

高水位線，（）上的最后一個日志條目，并且該條目被成功復(fù)制到（）>（），意味著該日志被整個集群接受

該條目在日志中的索引稱為高水位線索引。領(lǐng)導(dǎo)者僅將數(shù)據(jù)暴露給高水印索引。

例如，為了處理不可重復(fù)讀取并確保數(shù)據(jù)一致性，會跟蹤高水位線，這是特定分區(qū)的最大偏移量。用戶只能看到達到高水位線的消息。

4.9 Phi 累積故障檢測

使用歷史心跳信息的自適應(yīng)閾值

通用應(yīng)計故障檢測器不會判斷服務(wù)器是否處于活動狀態(tài)，但會輸出有關(guān)服務(wù)器的可疑級別。

eg（開源分布式數(shù)據(jù)庫）使用 Phi 累積故障檢測算法來確定集群中節(jié)點的狀態(tài)

4.10 - 記錄預(yù)寫日志

預(yù)寫日志是針對操作系統(tǒng)中文件系統(tǒng)不一致問題的高級解決方案。當(dāng)我們提交寫入操作系統(tǒng)的文件緩存時，業(yè)務(wù)會認為已經(jīng)提交成功；有一個時差。如果此時機器宕機，緩存中的數(shù)據(jù)就會丟失，導(dǎo)致完整性丟失。

為了解決這個問題，例如es等都采用了- log的機制來避免這個問題

：

：

4.11 段日志

將日志拆分為多個較小的文件，而不是單個大文件，以便于操作。

在啟動時讀取單個日志文件可能會增長并成為性能瓶頸。較舊的日志會定期清理，很難對單個大文件進行清理操作。

單個日志被分成多個段。日志文件在指定的大小限制后滾動。使用日志分段，需要一種簡單的方法將邏輯日志偏移（或日志序列號）映射到日志段文件。

這其實很常見。比如我們實際業(yè)務(wù)應(yīng)用配置的日志，一般都是按天拆分，固定大小網(wǎng)站建設(shè)，并不是所有的日志都放在一個日志文件中。

再比如es的分段存儲，一個就是一個小的存儲文件

4.12 檢查

在分布式系統(tǒng)中，當(dāng)數(shù)據(jù)在組件之間移動時，從節(jié)點獲取的數(shù)據(jù)可能會損壞。

計算校驗和并將其與數(shù)據(jù)一起存儲。

要計算校驗和，請使用加密哈希函數(shù)，例如 MD5、SHA-1、SHA-256 或 SHA-512。哈希函數(shù)接受輸入數(shù)據(jù)并產(chǎn)生一個固定長度的字符串（包含字母和數(shù)字）；這個字符串稱為校驗和。

當(dāng)系統(tǒng)存儲一些數(shù)據(jù)時，它會計算數(shù)據(jù)的校驗和，并將校驗和與數(shù)據(jù)一起存儲。當(dāng)客戶端檢索數(shù)據(jù)時，它會驗證從服務(wù)器接收到的數(shù)據(jù)是否與存儲的校驗和匹配。如果沒有，客戶端可能會選擇從另一個副本中檢索該數(shù)據(jù)。

HDFS 并將每個文件的校驗和與數(shù)據(jù)一起存儲。

4.13 灰色總結(jié)