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

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

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

1.1 集中式服務(wù)

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

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

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

1.2 去 IOE 運(yùn)動(dòng)

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

1.3 分布式服務(wù)

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

特點(diǎn)很多，大致就是下面5個(gè)：

• 分布：這個(gè)就是多臺(tái)計(jì)算機(jī)都被放置在了不同的位置

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

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

• 全局時(shí)鐘：多個(gè)主機(jī)上的事件先后順序會(huì)對(duì)結(jié)果產(chǎn)生影響，這也是分布式場(chǎng)景中非常復(fù)雜的一個(gè)問題

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

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

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

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

節(jié)點(diǎn)宕機(jī)問題

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

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

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

1.5 衡量分布式系統(tǒng)的性能標(biāo)準(zhǔn)

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

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

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

一致性：副本管理

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

1.6 對(duì)于一致性的擴(kuò)展

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

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

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

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

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

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

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

二、分布式事務(wù)

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

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

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

2.1 2PC是個(gè)什么東西

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

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

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

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

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

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

2PC 階段二：提交事務(wù)

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

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

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

2PC 的4個(gè)缺點(diǎn)：性能

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

2PC 的4個(gè)缺點(diǎn)：?jiǎn)吸c(diǎn)故障

那我們剛剛也知道了，協(xié)調(diào)者才是這個(gè)事務(wù)的核心。假如此時(shí)協(xié)調(diào)者故障宕機(jī)，會(huì)導(dǎo)致通知無法傳達(dá)到參與者的問題，比如收不到那個(gè) commit or  rollback ，整一個(gè)事務(wù)便會(huì)停滯。

2PC 的4個(gè)缺點(diǎn)：數(shù)據(jù)不一致

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

2PC 的4個(gè)缺點(diǎn)：不存在容錯(cuò)機(jī)制

這個(gè)協(xié)調(diào)者需要收到所有的節(jié)點(diǎn)反饋準(zhǔn)備完成才會(huì)下達(dá) commit  的指示，任意一個(gè)參與者的響應(yīng)沒有收到，協(xié)調(diào)者就會(huì)進(jìn)行等待，而且只要存在一個(gè)宕機(jī)的節(jié)點(diǎn)，都會(huì)使得整個(gè)事務(wù)失敗回滾。

2.2 3PC 是個(gè)啥東西

在 2PC 的前提下進(jìn)行了一個(gè)改良，將 2PC 中的準(zhǔn)備階段進(jìn)行拆分，形成 can commit，pre commit，do commit  三個(gè)階段。

并且引入超時(shí)機(jī)制，一旦事務(wù)參與者在指定時(shí)間內(nèi)沒有收到協(xié)調(diào)者的 commit or rollback 指令，就會(huì)自動(dòng)進(jìn)行本地  commit，解決協(xié)調(diào)者的單點(diǎn)故障問題

3PC 第一階段 cancommit

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

3PC 第二階段 precommit

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

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

三、分布式一致性算法

3.1 Paxos 算法

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

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

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

3.2 Paxos 中存在的角色及與 Zookeeper 集群的關(guān)系

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

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

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

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

3.3 Raft 算法

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

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

這里假設(shè)一個(gè)節(jié)點(diǎn)有3種不同的狀態(tài)

第一種，follower state(無線條)

第二種，candidate state(虛線)

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

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

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

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

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

3.4 ZAB 協(xié)議

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

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

3.5 Quorum NWR 機(jī)制

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

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

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

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

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

回到 Quorum NWR 機(jī)制 的 NWR 到底指什么

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

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

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

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

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

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

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

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

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

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

3.6 CAP 理論

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

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

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

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

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

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

CAP  只能3選2，因?yàn)樵诜植际较到y(tǒng)中，容錯(cuò)性P肯定是必須有的，所以這時(shí)候無非就兩種情況，網(wǎng)絡(luò)問題導(dǎo)致要么錯(cuò)誤返回，要么阻塞等待，前者犧牲了一致性，后者犧牲了可用性。舉個(gè)例子，比如  HBase 就是追求數(shù)據(jù)的一致性的，而 Cassandra 則是可用性。

經(jīng)驗(yàn)總結(jié)：

• 不要花費(fèi)精力浪費(fèi)在設(shè)計(jì)同時(shí)滿足CAP的分布式系統(tǒng)

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

• 對(duì)于單機(jī)軟件，因?yàn)椴挥每紤]P，所以肯定是 CA 型，比如 MySQL

• 對(duì)于分布式軟件，因?yàn)橐欢〞?huì)考慮P，所以又不能兼顧A和C的情況下，只能在A和C做權(quán)衡，比如 HBase, Redis 等。做到服務(wù)基本可用，并且數(shù)據(jù)最終一致即可。

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

3.7 BASE 理論

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

不是強(qiáng)一致，而是最終一致。不是高可用，而是基本可用。

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

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

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

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

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

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

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

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

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

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