web開發(fā)中分布式系統(tǒng)的基礎理論有哪些

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

成都創(chuàng)新互聯(lián)專注于嶧城企業(yè)網(wǎng)站建設,成都響應式網(wǎng)站建設,商城網(wǎng)站建設。嶧城網(wǎng)站建設公司,為嶧城等地區(qū)提供建站服務。全流程按需求定制網(wǎng)站，專業(yè)設計，全程項目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務

一、分布式系統(tǒng)與 Zookeeper 的關系

1.1 集中式服務

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

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

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

1.2 去 IOE 運動

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

1.3 分布式服務

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

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

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

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

• 并發(fā)：多個機器同時操作一份數(shù)據(jù)可能會引發(fā)的數(shù)據(jù)不一致問題

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

• 各種故障：某節(jié)點宕機，網(wǎng)絡不好···突發(fā)情況

1.4 分布式場景中經(jīng)常遇到的幾個問題

• 通信異常：其實就是網(wǎng)絡問題，導致多節(jié)點狀態(tài)下數(shù)據(jù)不一致

• 網(wǎng)絡孤立：這個其實就是各個子網(wǎng)絡內(nèi)部正常，但是整個系統(tǒng)的網(wǎng)絡是不正常的。導致局部數(shù)據(jù)不一致的問題

節(jié)點宕機問題

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

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

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

1.5 衡量分布式系統(tǒng)的性能標準

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

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

• 可擴展性：指可以通過擴大機器規(guī)模達到提高系統(tǒng)性能的效果

一致性：副本管理

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

1.6 對于一致性的擴展

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

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

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

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

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

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

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

二、分布式事務

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

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

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

2.1 2PC是個什么東西

在事務的參與過程中會產(chǎn)生多個角色，暫時我們先這么理解，協(xié)調者負責事務的發(fā)起，而參與者負責執(zhí)行事務。

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

2PC 階段一：執(zhí)行事務

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

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

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

2PC 階段二：提交事務

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

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

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

2PC 的4個缺點：性能

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

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

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

2PC 的4個缺點：數(shù)據(jù)不一致

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

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

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

2.2 3PC 是個啥東西

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

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

3PC 第一階段 cancommit

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

3PC 第二階段 precommit

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

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

三、分布式一致性算法

3.1 Paxos 算法

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

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

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

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

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

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

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

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

3.3 Raft 算法

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

這里說到了，Raft 是實現(xiàn)分布式共識算法的一個協(xié)議

這里假設一個節(jié)點有3種不同的狀態(tài)

第一種，follower state(無線條)

第二種，candidate state(虛線)

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

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

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

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

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

3.4 ZAB 協(xié)議

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

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

3.5 Quorum NWR 機制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.6 CAP 理論

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

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

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

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

• 放棄 A：一旦系統(tǒng)遇到網(wǎng)絡分區(qū)或者其他故障時，服務需要等待一段時間，在等待時間內(nèi)就無法正常對外提供服務，即服務不可用

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

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

經(jīng)驗總結：

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

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

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

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

所以，就產(chǎn)生了 BASE 理論。

3.7 BASE 理論

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

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

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

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

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

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

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

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

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

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

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

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

網(wǎng)頁名稱：web開發(fā)中分布式系統(tǒng)的基礎理論有哪些
本文網(wǎng)址：http://muchs.cn/article18/jpecgp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供用戶體驗、網(wǎng)站營銷、移動網(wǎng)站建設、定制開發(fā)、網(wǎng)站策劃、品牌網(wǎng)站建設

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)