web開發中分布式系統的基礎理論有哪些

這篇文章給大家介紹web開發中分布式系統的基礎理論有哪些，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

一、分布式系統與 Zookeeper 的關系

1.1 集中式服務

我們先從服務部署架構的發展歷程說起，其實無非就是 集中式 和 分布式  ，集中式就是說，什么我都是由一臺機器搞定的。分布式就是多臺服務器聯合完成。所以在一開始的時候一般都是從一臺服務器開始，將我們的服務部署上去，然后就是一些老套路，Web  應用就部署在 Tomcat 上開放 8080 端口提供服務，然后它需要的一個數據庫服務就開放 3306  端口提供。它的優點就在于結構，部署，項目架構都比較簡單。

然后再根據業務的發展去擴展，那擴展同樣也可以分為兩種方式，一種是橫向擴展，一種為縱向擴展。既然一臺搞不定，那就要不提升這個服務器的性能，要不就整多幾臺一起上。但是我們想想，也不是個人就會把服務器安排的服服帖帖的呀，這臺機子一掛，那就全掛了。而且大型主機的購買，還有研發，維護人才，那都是得花大價錢的。這里給大家擴展一個  “摩爾定律”

反正簡單點來說，就是我花兩倍的錢，根本買不到兩倍的性能。但是橫向擴展就不一樣了，一個人打不過，叫多幾個人一起打不就行了?

1.2 去 IOE 運動

阿里巴巴搞出來的一個口號，具體點就是  IBM小型機，Oracle數據庫，EMC的高端存儲，有興趣的也可以了解一下。因為當時面臨的問題是，企業如果需要提升單機處理能力，成本會很高且性價比極低。還整天怕這怕那的，一宕機就整個服務停掉。慢慢的國內很多公司跟著一起響應，分布式就起來了。

1.3 分布式服務

分布式系統有著它具體的定義：分布式系統是一個硬件或者軟件組件分布在不同的網絡計算機上，彼此之間僅通過消息傳遞進行通信和協調的系統。所以就是一堆計算機聯合起來對外提供服務，但是對于用戶來說，像是一臺機子在完成這事。

特點很多，大致就是下面5個：

• 分布：這個就是多臺計算機都被放置在了不同的位置

• 對等：集群中的多個工作節點都是一個貨色，干的都一樣的活兒。而且存在副本概念

• 并發：多個機器同時操作一份數據可能會引發的數據不一致問題

• 全局時鐘：多個主機上的事件先后順序會對結果產生影響，這也是分布式場景中非常復雜的一個問題

• 各種故障：某節點宕機，網絡不好···突發情況

1.4 分布式場景中經常遇到的幾個問題

• 通信異常：其實就是網絡問題，導致多節點狀態下數據不一致

• 網絡孤立：這個其實就是各個子網絡內部正常，但是整個系統的網絡是不正常的。導致局部數據不一致的問題

節點宕機問題

• 分布式三態：成功，失敗，超時這3種狀態引出的各個問題。請求發送和結果響應都有可能丟失，無法確定消息是否發送/處理成功

• 數據丟失：這個一般通過副本機制，從其它節點讀取解決，或者對于有狀態的節點來說丟失數據就可以通過恢復狀態來解決。

• 異常處理原則：任何在設計階段考慮到的異常情況都必須假設一定會在實際運行中發生

1.5 衡量分布式系統的性能標準

• 性能：主要就是吞吐能力，響應延遲，并發能力。系統某一時間可以處理的數據總量，通常是用系統每秒處理的總數據量衡量，而響應延遲指的是完成某一功能所需要的的時間。并發能力就是同時完成某一功能的能力，通常就是用  QPS 衡量

• 可用性：在面對各種異常時可以正確提供服務的能力。比如我們常說的 5個9 就是指一年內只有5分鐘的宕機時間。6個9 就是 31 秒

• 可擴展性：指可以通過擴大機器規模達到提高系統性能的效果

一致性：副本管理

但是這些標準都是一個方面要求太高之后會帶動另外一方面變差，比如說我們需要做到高可用，可能需要多個副本，但是多個副本的狀態下，對于數據的一致性又很難去做到了。然后高吞吐下又很難做到低延遲，所以我們需要針對自己的業務場景去進行考量。

1.6 對于一致性的擴展

• 強一致性：寫操作完成之后，讀操作一定能讀到最新數據，在分布式場景中這樣是非常難實現的，比如  Paxos算法，Quorum機制，ZAB協議都是干這個事的。

• 弱一致性：不承諾可以立即讀到寫入的值，也不承諾多久之后數據能夠達到一致，但會盡可能的保證到某個時間級別(比如XX時，XX分，XX秒后)，數據可達到一致性狀態。

它還有一個特例叫做最終一致性，就是盡可能快的保證數據的一致。但是這個快到底是多快，就沒有準確定義了。好比女票想要吃到炸雞，你給點了份外賣，可是美團騎手，餓了嗎騎手也說不準什么時候送到，他只能說保證盡快送到。就這么個意思。

因為最終一致性實在是太弱了所以我們還有一些特例情況會出現讀寫一致性，它是指用戶讀取自己寫入的結果永遠可以第一時間看到自己更新的內容，這個就像微信朋友圈一樣的，我們發出來的東西，微信是一定會讓我們看到的，可是朋友們是不是你發了立刻就能看到，那可就說不準了。

還有一些單調讀一致性，因果一致性就不展開說明了，有興趣的小伙伴可以自行搜索。

總而言之，為了保證系統的高可用，防止單點故障引發的問題，并能夠讓分布在不同節點上的副本都能正常為用戶提供服務，這時，我們的 Zookeeper  就應運而生了。它就能幫助我們解決這個分布式系統中數據一致性的問題

需要解決這個問題我們需要了解分布式事務，分布式一致性算法，Quorum 機制，CAP 和 BASE 理論，接下來我們慢慢去展開

二、分布式事務

事務：單機存儲系統中用來保證存儲系統的數據狀態一致性，這是不是讀起來有點拗口，沒事，我們換個說法，廣義上的事務，就是指一個事情的所有操作，要不全部成功，要不全部失敗，沒有中間狀態。狹義一點，那就是數據庫做的那些操作。特征也很簡單，就是耳熟能詳的  ACID 。

分布式系統中每個節點都僅僅知道自己的操作是否成功，但是不知道其它節點是個啥情況，這就有可能導致各節點的狀態可能是不一致的，所以為了實現跨越多節點且保證事務的  ACID 時，需要引入一個協調者，然后參與事務的各個節點都叫做參與者

典型的套路就是 2PC 和 3PC，接下來我們慢慢展開

2.1 2PC是個什么東西

在事務的參與過程中會產生多個角色，暫時我們先這么理解，協調者負責事務的發起，而參與者負責執行事務。

假定存在上面的3個角色，分別是一個協調和兩個參與，此時我們需要 A ，B 執行一個事務，并且要求這個事務，要么同時成功，要么同時失敗。

2PC 階段一：執行事務

此時協調者會 先發出一個命令，要求參與者A，參與者B都都去執行這個事務，但是不提交

說的再詳細一點，就會產生寫 redo，undo 的日志，鎖定資源，執行事務。但是執行完了之后，直接向協調者打報告，詢問一下，大哥我能提交嗎?

這個在日常寫Java的過程中應該經常遇到，就是前面寫了一大堆操作，但是等到最后一定會寫一個 conn.commit() 這樣的東西，這就是所謂的  執行但不提交

2PC 階段二：提交事務

當協調者收到第一階段中的所有事務參與者(圖中的A，B)的反饋(這個反饋簡單理解為，告訴協調者前面的第一階段執行成功了)時，就發送命令讓所有參與者提交事務。

如果要說的再細一點，那就是協調者收到反饋，且所有參與者均響應可以提交，則通知參與者進行 commit，否則 rollback

所以 2PC 也叫做二階段提交，其實就是這么簡單分成了兩步，一步執行，一步提交。

2PC 的4個缺點：性能

整個流程看下來就知道這明顯產生了同步阻塞，各個需要操作數據庫的節點都占用了數據庫的資源。只有當協調者收到所有節點都準備完畢的反饋，事務協調者才會通知  commit or rollback，而參與者執行完這個 commit or rollback 的操作后，才會去釋放資源。

2PC 的4個缺點：單點故障

那我們剛剛也知道了，協調者才是這個事務的核心。假如此時協調者故障宕機，會導致通知無法傳達到參與者的問題，比如收不到那個 commit or  rollback ，整一個事務便會停滯。

2PC 的4個缺點：數據不一致

協調者在第二階段會發送 commit or  rollback。可是這并不能保證每一個節點都正常收到這個命令，所以會可能竄在，參與者A收到了命令，提交了事務，但是參與者B沒有。所以網絡波動是永恒的病因，你永遠無法躲開這個因素。

2PC 的4個缺點：不存在容錯機制

這個協調者需要收到所有的節點反饋準備完成才會下達 commit  的指示，任意一個參與者的響應沒有收到，協調者就會進行等待，而且只要存在一個宕機的節點，都會使得整個事務失敗回滾。

2.2 3PC 是個啥東西

在 2PC 的前提下進行了一個改良，將 2PC 中的準備階段進行拆分，形成 can commit，pre commit，do commit  三個階段。

并且引入超時機制，一旦事務參與者在指定時間內沒有收到協調者的 commit or rollback 指令，就會自動進行本地  commit，解決協調者的單點故障問題

3PC 第一階段 cancommit

協調者先詢問：哎你們這幫人到底能不能行?參與者就根據自身的實際情況回答yes or no。

3PC 第二階段 precommit

如果參與者都是返回同意，協調者則向所有參與者發送預提交請求，并進入準備階段，這里的準備階段其實就是讓參與者鎖定資源，等待指令的意思，然后就是事務的執行，此時也像  2PC 一樣，執行但不提交。然后等待協調者的指令，此時如果遲遲等不到指令，一段時間后就會自行本地提交

但是這樣也會存在弊端，比如協調者成功給1，2參與者都發送回滾，然后3剛好就沒收到，那么3就自動提交了，所以超時機制其實并不能完全保證數據的一致性

三、分布式一致性算法

3.1 Paxos 算法

不知道大家有沒有看到我上一年的那篇 從零開始的高并發(三)--- Zookeeper集群的搭建和leader選舉  如果需要詳細了解，推薦跳轉到那篇哦。

Paxos 算法是一個名字叫 Lesile Lamport 提出的一種基于消息傳遞且具有高度容錯特性的一致性算法

是不是覺得繞口?沒事，我們只需要知道，分布式系統中不可避免的會發生進程被kill，消息延遲，重復，丟失···一系列問題，Paxos  算法就是在這些異常情況下的仍然保證數據一致性的東西。那這東西和 Zookeeper 有啥關系呢?Zookeeper 是存在一個 ZAB 協議的，但是這個 ZAB  協議底層就是封裝了 Paxos 算法的。

3.2 Paxos 中存在的角色及與 Zookeeper 集群的關系

• Proposer 提議者：顧名思義就是發起提案的人

• Acceptor 接受者：它們是可以表決的，可以接受或者否決提案

• Learner 學習者：提案被超過半數的 Acceptor 接受的話，就學習這個提案

映射到 Zookeeper 集群中，就分別是  leader，follower，observer，它們有點像是主席，人大代表，和全國老百姓的關系，主席提出一個提案，人大代表參與投票，全國老百姓被動接受，大概就是這么個感覺。相比于之前的  2PC，3PC，它只需要半數通過即可提交。所以這種屬于弱一致性，2PC，3PC這些就屬于強一致性

3.3 Raft 算法

請點擊這個鏈接，相信你一定能夠很快掌握。http://thesecretlivesofdata.com/raft/  我這里還是小小的說明一下吧，這個是一個PPT的形式，告訴你，Raft 到底是個什么東西，非常好懂，我這里跳過前面的一些東西，直奔主題

這里說到了，Raft 是實現分布式共識算法的一個協議

這里假設一個節點有3種不同的狀態

第一種，follower state(無線條)

第二種，candidate state(虛線)

第三種，leader state(實線) 記住leader是從 candidate 候選人那里選出來的

首先我們一上來，所有的節點都是 follower state

接下來，所有的 follower 節點都尋找 leader ，當他們找不到的時候，就會自發成為候選人發起投票(問其它人是否贊成我成為  leader)，什么情況才會找不到呢?那肯定就是 leader 掛了嘛

此時它就發送給其它節點投票的提案，然后其它節點也會給予它反饋，當它接收到超過半數的節點的反饋的時候，它就可以順理成章的成為 leader 了。

之后寫數據的請求就會直接發給leader，由 leader 廣播給其它的  follower，此時也是只要超過半數節點返回正反饋，那這個寫數據的事務就會被執行，然后 leader 再給它們發送提交命令，事務就算執行成功了。

3.4 ZAB 協議

內容在 從零開始的高并發(四)--- Zookeeper的分布式隊列

Zookeeper 的底層實現就是 ZAB  協議，它實現了崩潰恢復(leader崩潰)和消息廣播(客戶端寫數據Zookeeper要保證多節點都成功寫入)功能。主要就是保證在leader服務器上提交的事務最終讓所有服務器都提交，并確保丟棄掉只在leader服務器上所提出的事務

3.5 Quorum NWR 機制

Quorum NWR：Quorum  機制是分布式場景中常用的，用來保證數據安全，并且在分布式環境中實現最終一致性的投票算法。這種算法的主要原理來源于鴿巢原理。它最大的優勢，既能實現強一致性，而且還能自定義一致性級別。

鴿巢原理，又名狄利克雷抽屜原理、鴿籠原理。

其中一種簡單的表述法為： 若有n個籠子和n+1只鴿子，所有的鴿子都被關在鴿籠里，那么至少有一個籠子有至少2只鴿子。

另一種為：若有n個籠子和kn+1只鴿子，所有的鴿子都被關在鴿籠里，那么至少有一個籠子有至少k+1只鴿子。

為什么從抽屜原理說起?一來大家對這個比較熟悉，也容易理解，二來它與 Quorum  機制有異曲同工的地方。抽屜原理，2個抽屜每個抽屜最多容納2個蘋果，現在有3個蘋果無論怎么放，其中的一個抽屜里面肯定會有2個蘋果。那么我們把抽屜原理變變型，2個抽屜一個放了2個紅蘋果，另一個放了2個青蘋果，我們取出3個蘋果，無論怎么取至少有1個是紅蘋果，這個理解起來也很簡單。我們把紅蘋果看成更新了的有效數據，青蘋果看成未更新的無效數據。便可以看出來，不需要更新全部數據(并非全部是紅蘋果)我們就可以得到有效數據，當然我們需要讀取多個副本(取出多個蘋果)。

回到 Quorum NWR 機制 的 NWR 到底指什么

N：復制的節點數，即一份數據被保存的副本數。 W：寫操作成功的節點數，即每次數據寫入寫成功的副本數。W 肯定是小于等于 N 的。  R：讀操作獲取最新版本數據所需的最小節點數，即每次讀取成功至少需要讀取的副本數。

總結：這三個因素決定了可用性，一致性 和 分區容錯性。只要保證(W + R >  N)就一定能讀取到最新的數據，數據一致性級別完全可以根據讀寫副本數的約束來達到強一致性!

分以下三種情況討論：前提，當 N 已經固定了。

W = 1, R = N，Write Once Read All

在分布式環境中，寫一份，那么如果要讀取到最新數據，就必須要讀取所有節點，然后取最新版本的值了。寫操作高效，但是讀操作效率低。一致性高，分區容錯性差，可用性低

R = 1, W = N, Read Only Write All

在分布式環境中，所有節點都同步完畢，才能讀取，所以只要讀取任意一個節點就可以讀取到最新數據。讀操作高效，但是寫操作效率低。分區容錯性好，一致性差，實現難度更高，可用性高

W = Q, R = Q where Q = N/2 + 1

可以簡單理解為寫超過一半節點，那么讀也超過一半節點，取得讀寫性能平衡。一般應用適用，讀寫性能之間取得平衡。如 N=3, W=2,  R=2，分區容錯性，可用性，一致性取得一個平衡。而 ZooKeeper 就是這么去設計的

需要補充的是，Zookeeper  并沒有實現必須要客戶端讀取超過半數的節點，所以它是允許客戶端讀取到的不是最新同步完成的數據的，但是可能性比較小。數據沒有同步完成的節點其實客戶端也大概率是連接不上的，因為無論是網絡問題還是機器問題導致  leader 發送數據過去它做不了的話，客戶端肯定也連不上它。要是剛好就是在同步數據的中間狀態客戶端發起了訪問的話，也是有辦法解決的，可以自己了解一下。

3.6 CAP 理論

• CAP 理論：2000 年 7 月份被首次提出，CAP 理論告訴我們，一個分布式系統不可能同時滿足 C,A,P 三個需求

• C：Consistency，強一致性，分布式環境中多個數據副本保持一致  A：Availability，高可用性，系統提供的服務必須一直處于可用，對于用戶的每一個操作請求總是能在有限時間內返回結果 P：Partition  Tolerance 分區容錯性，分布式系統在遇到任何網絡分區故障時，仍然需要能夠保證對外提供滿足一致性和可用性的服務

既然一個分布式系統不能同時滿足 C,A,P 三個需求，我們就要就我們的需求去取舍了。

• 放棄 P：最簡單的極端做法，就是放置在一個節點上，也就只有一個數據副本，所有讀寫操作就集中在一臺服務器上，有單點故障問題。放棄 P  也就意味著放棄了系統的可擴展性，所以分布式系統一般來說，都會保證 P

• 放棄 A：一旦系統遇到網絡分區或者其他故障時，服務需要等待一段時間，在等待時間內就無法正常對外提供服務，即服務不可用

• 放棄 C：事實上，放棄一致性是指放棄數據的強一致性，而保留最終一致性，具體多久達到數據同步取決于存儲系統的設計

CAP  只能3選2，因為在分布式系統中，容錯性P肯定是必須有的，所以這時候無非就兩種情況，網絡問題導致要么錯誤返回，要么阻塞等待，前者犧牲了一致性，后者犧牲了可用性。舉個例子，比如  HBase 就是追求數據的一致性的，而 Cassandra 則是可用性。

經驗總結：

• 不要花費精力浪費在設計同時滿足CAP的分布式系統

• 分區容錯性往往是分布式系統必然要面對和解決的問題。所以應該把精力放在如何根據業務特點在A和C之間尋求平衡。

• 對于單機軟件，因為不用考慮P，所以肯定是 CA 型，比如 MySQL

• 對于分布式軟件，因為一定會考慮P，所以又不能兼顧A和C的情況下，只能在A和C做權衡，比如 HBase, Redis 等。做到服務基本可用，并且數據最終一致即可。

所以，就產生了 BASE 理論。

3.7 BASE 理論

多數情況下，其實我們也并非一定要求強一致性，部分業務可以容忍一定程度的延遲一致，所以為了兼顧效率，發展出來了最終一致性理論 BASE，來自 ebay  的架構師提出。BASE理論全稱：全稱：Basically Available(基本可用)，Soft state(軟狀態),和 Eventually  consistent(最終一致性)三個 短語的縮寫。核心思想是：即使無法做到強一致性，但每個應用都可  以根據自身業務特點，采用適當的方式來使系統達到最終一致性。一句話概括，做事別走極端，BASE 是對 CAP 理論中的 C 和 A 進行權衡得到的結果。

不是強一致，而是最終一致。不是高可用，而是基本可用。

Basically Available(基本可用)：基本可用是指分布式系統在出現故障的時候，允許損失部分可用性，即保證核心可用

例如淘寶雙11，為保護系統穩定性，正常下單，其他邊緣服務可暫時不可用。部分非核心服務宕機此時是允許的。

Soft  State(軟狀態)：軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分布式存儲中一般一份數據至少會有三個副本，允許不同節點間副本同步的延時就是軟狀態的體現。通俗的講：允許存在不同節點同步數據時出現延遲，且出現數據同步延遲時存在的中間狀態也不會影響系統的整體性能

Eventually  Consistent(最終一致)：最終一致性是指系統中的所有數據副本經過一定時間后，最終能夠達到一致的狀態。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況，要求最終達到一致，而不是實時強一致

總的來說，我們提到了集中式 和 分布式服務部署架構的分析，設計分布式系統會遇到的各種難題：數據一致性的問題

2PC 和 3PC是通用的思路實現，還是有缺點。Paxos Raft ZAB  就算出現了分布式網絡通信異常等相關棘手的問題，以上這些算法也能實現一致性

議會制 Quorum NWR機制：R + W > N ===> 少數服從多數

一致性 和 可用性的沖突問題，CAP 和 BASE：分布式系統一定要滿足 P，只能在 C 和 A 中做權衡

絕大部分系統都是 BASE 系統(基本可用 + 最終一致)

關于web開發中分布式系統的基礎理論有哪些就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。