分布式学习-总结
文章目錄
- 分布式理論
- 分布式系統(tǒng)定義以及面臨的問題
- 分布式系統(tǒng)定義
- 分布式面臨的問題
- 通信異常
- 網(wǎng)絡(luò)分區(qū)
- 三態(tài)
- 節(jié)點(diǎn)故障
- 分布式理論：一致性概念
- 分布式一致性的提出
- 強(qiáng)一致性
- 弱一致性
- 最終一致性
- 分布式事務(wù)
- CAP定理
- 什么是CAP理論？
- 為什么只能3選2
- 能不能解決3選2的問題
- BASE理論
- 什么是BASE理論？
- Basically Available（基本可用）
- 一致性協(xié)議2PC
- 什么是2PC？
- 階段一：提交事務(wù)請求
- 1.事務(wù)詢問
- 2.執(zhí)行事務(wù)
- 3.各參與者向協(xié)調(diào)者反饋事務(wù)詢問的響應(yīng)
- 階段二：執(zhí)行事務(wù)提交
- 提交事務(wù)步驟如下：
- 1.發(fā)送提交請求
- 2.事務(wù)提交
- 3.反饋事務(wù)提交結(jié)果
- 4.完成事務(wù)
- 中斷事務(wù)步驟如下：
- 1.發(fā)送事務(wù)回滾請求
- 2.事務(wù)回滾
- 3.反饋事務(wù)回滾結(jié)果
- 4.中斷事務(wù)
- 2PC優(yōu)缺點(diǎn)
- 優(yōu)點(diǎn)
- 缺點(diǎn)
- 一致性協(xié)議3PC
- 什么是三階段提交
- 階段一：CanCommit
- 階段二：PreCommit
- 階段三：doCommit
- 2pc和3pc對比：
- 一致性算法Paxos
- 背景
- 相關(guān)概念
- 問題描述
- 推導(dǎo)過程
- paxos算法描述
- 如何保證paxos算法的活性
- 一致性算法Raft
- 分布式系統(tǒng)設(shè)計(jì)策略
- 心跳檢測
- 高可用設(shè)計(jì)
- 容錯(cuò)性
- 負(fù)載均衡
- 分布式架構(gòu)網(wǎng)絡(luò)通信
- 基本概念
- 什么是RPC
- RMI
- BIO、NIO、AIO
- Netty
- IO編程
- NIO編程
- Netty編程
- 基于Netty自定義RPC
分布式理論
分布式系統(tǒng)定義以及面臨的問題
分布式系統(tǒng)定義
分布式系統(tǒng)是一個(gè)硬件或軟件組件分布在不同的網(wǎng)路計(jì)算機(jī)上，彼此之間僅僅通過消息傳遞進(jìn)行通信和協(xié)調(diào)的系統(tǒng)。
分布式面臨的問題
通信異常
由于網(wǎng)絡(luò)本身的不可靠性，出現(xiàn)消息丟失、消息延遲
網(wǎng)絡(luò)分區(qū)
由于網(wǎng)絡(luò)發(fā)生異常情況，導(dǎo)致分布式系統(tǒng)中部分節(jié)點(diǎn)之間的網(wǎng)絡(luò)延遲不斷增大，最終導(dǎo)致組成分布式系統(tǒng)中有部分節(jié)點(diǎn)能夠正常通信，網(wǎng)絡(luò)之間出現(xiàn)了網(wǎng)絡(luò)不連通，但各個(gè)子網(wǎng)絡(luò)的內(nèi)部網(wǎng)絡(luò)是正常的，從而導(dǎo)致整個(gè)系統(tǒng)的網(wǎng)絡(luò)環(huán)境被切分成了若干個(gè)孤立的區(qū)域，分布式系統(tǒng)就會(huì)出現(xiàn)局部小集群，在極端情況下，這些小集群會(huì)獨(dú)立完成原本需要整個(gè)分布式系統(tǒng)才能完成的功能，包括數(shù)據(jù)的事務(wù)處理，這就是對分布式一致性提出非常大的挑戰(zhàn)。
三態(tài)
分布式系統(tǒng)每一次請求與響應(yīng)存在特有的“三態(tài)”概念，即成功、失敗和超時(shí)。在分布式系統(tǒng)中，由于網(wǎng)絡(luò)是不可靠的，雖然絕大部分情況下，網(wǎng)絡(luò)通信能夠接收到成功或失敗的響應(yīng)，但當(dāng)網(wǎng)絡(luò)出現(xiàn)異常的情況下，就會(huì)出現(xiàn)超時(shí)現(xiàn)象，通常有以下兩種情況：
1.由于網(wǎng)絡(luò)原因，該請求并沒有被成功的發(fā)送到接收方，而是在發(fā)送過程就發(fā)生了丟失現(xiàn)象。
2.改請求成功的被接收方接收后，并進(jìn)行了處理，但在響應(yīng)反饋給發(fā)送方過程中，發(fā)生了消息丟失現(xiàn)象。
節(jié)點(diǎn)故障
節(jié)點(diǎn)故障是分布式系統(tǒng)下另一個(gè)比較常見的問題，指的是組成分布式系統(tǒng)的服務(wù)器節(jié)點(diǎn)出現(xiàn)的**宕機(jī)或“僵死”**現(xiàn)象，根據(jù)經(jīng)驗(yàn)來說，每個(gè)節(jié)點(diǎn)都有可能出現(xiàn)故障，并且經(jīng)常發(fā)生
分布式理論：一致性概念
分布式一致性的提出
在分布式系統(tǒng)中要解決的一個(gè)重要問題就是數(shù)據(jù)的復(fù)制。在我們的日常開發(fā)中，相信有很多人遇到過這樣的問題：假設(shè)客戶端C1將系統(tǒng)中的一個(gè)值K由V1更新為V2，但客戶端C2無法立即讀取到最新值，需要在一段時(shí)間之后才能讀取到，這個(gè)例子就是常見的數(shù)據(jù)庫之間復(fù)制延遲問題。
分布式系統(tǒng)對于數(shù)據(jù)的復(fù)制需求一般都來自于一下兩個(gè)原因：
數(shù)據(jù)復(fù)制在可用性和性能方面帶來的好處不言而喻，然后數(shù)據(jù)復(fù)制帶來的一致性挑戰(zhàn)也是不得不面對。
數(shù)據(jù)一致性是指對一個(gè)副本數(shù)據(jù)進(jìn)行更新的時(shí)候，必須確保也能夠更新其他的副本，否則不同副本之間的數(shù)據(jù)將不一致。
那么如果解決這個(gè)問題？一種思路就是“既然是由于延時(shí)動(dòng)作引起的問題，那我們可以將寫入的動(dòng)作阻塞，知道數(shù)據(jù)復(fù)制完成后，才完成寫入動(dòng)作”，一些系統(tǒng)架構(gòu)也是這樣設(shè)計(jì)的，但是這種思路之后會(huì)引入新的問題：寫入的性能。如果你的應(yīng)用場景有非常多的寫請求，那么使用這個(gè)思路以后，后續(xù)的寫請求都將會(huì)阻塞在前一個(gè)請求的寫操作上，導(dǎo)致系統(tǒng)整體性能急劇下降。
總得來說，我們無法找到一種能夠滿足分布式系統(tǒng)所有系統(tǒng)屬性的分布式一致性解決方案。那么如何保證數(shù)據(jù)的一致性，又能夠不影響系統(tǒng)運(yùn)行的性能，是每一個(gè)分布式系統(tǒng)都需要重點(diǎn)考慮和權(quán)衡的，于是一致性級別由此誕生：
強(qiáng)一致性
這種一致性級別是最符合用戶直覺的，它要求系統(tǒng)寫入什么，讀出來的也會(huì)是什么，用戶體驗(yàn)好，但實(shí)現(xiàn)起來往往對系統(tǒng)的性能影響大。
優(yōu)點(diǎn)：用戶體驗(yàn)好
缺點(diǎn)：性能開銷大
弱一致性
這種一致性級別約束了系統(tǒng)在寫入成功后，不承諾立即可以讀到寫入的值，也不承諾多久之后數(shù)據(jù)能夠達(dá)到一致，但會(huì)盡可能保證到某個(gè)時(shí)間級別后，數(shù)據(jù)能夠達(dá)到一致性狀態(tài)
最終一致性
最終一致性是弱一致性的一個(gè)特例，系統(tǒng)會(huì)保證在一定時(shí)間內(nèi)，能夠達(dá)到一個(gè)數(shù)據(jù)一致的狀態(tài)。這里之所以最終一致性單獨(dú)提出來，是因?yàn)樗侨跻恢滦灾蟹浅Ｍ瞥绲囊环N一致性模型，也是業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上比較推崇的模型。
分布式事務(wù)
在單機(jī)數(shù)據(jù)庫中，我們很容易實(shí)現(xiàn)一套滿足ACID特性的事務(wù)處理系統(tǒng)，但在分布式數(shù)據(jù)庫中，數(shù)據(jù)分散在各臺不同的機(jī)器上，如何對這些數(shù)據(jù)進(jìn)行分布式事務(wù)處理具有非常大的挑戰(zhàn)。
分布式事務(wù)：是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器分別位于分布式系統(tǒng)的不同節(jié)點(diǎn)上，通常一個(gè)分布式事務(wù)中會(huì)涉及對多個(gè)數(shù)據(jù)源或業(yè)務(wù)系統(tǒng)的操作。
可以設(shè)想一個(gè)最典型的分布式事務(wù)場景:一個(gè)跨銀行的轉(zhuǎn)賬操作涉及調(diào)用兩個(gè)異地的銀行服務(wù),其中一個(gè)是本地銀行提供的取款服務(wù),另一個(gè)則是目標(biāo)銀行提供的存款服務(wù),這兩個(gè)服務(wù)本身是無狀態(tài)并且相互獨(dú)立的,共同構(gòu)成了一個(gè)完整的分布式事務(wù)。如果從本地銀行取款成功,但是因?yàn)槟撤N原因存款服務(wù)失敗了,那么就必須回滾到取款之前的狀態(tài),否則用戶可能會(huì)發(fā)現(xiàn)自己的錢不翼而飛了。
從這個(gè)例子可以看到,一個(gè)分布式事務(wù)可以看做是多個(gè)分布式的操作序列組成的,例如上面例子的取款服務(wù)和存款服務(wù),通常可以把這一系列分布式的操作序列稱為子事務(wù)。
因此,分布式事務(wù)也可以被定義為一種嵌套型的事務(wù),同時(shí)也就具有了ACID事務(wù)特性。但由于在分布式事務(wù)中,各個(gè)子事務(wù)的執(zhí)行是分布式的,因此要實(shí)現(xiàn)一種能夠保證ACID特性的分布式事務(wù)處理系統(tǒng)就顯得格外復(fù)雜,尤其是對于一個(gè)高訪問量,高并發(fā)的互聯(lián)網(wǎng)分布式系統(tǒng)來說
如果我們期望實(shí)現(xiàn)一套嚴(yán)格滿足ACID特性的分布式事務(wù),很可能出現(xiàn)的情況就是在系統(tǒng)的可用性和嚴(yán)格一致性之間出現(xiàn)沖突…因?yàn)楫?dāng)我們要求分布式系統(tǒng)具有嚴(yán)格一致性時(shí),很可能就需要犧牲掉系統(tǒng)的可用性。但毋庸置疑的一點(diǎn)是,可用性又是一個(gè)消費(fèi)者不允許我們討價(jià)還價(jià)的系統(tǒng)屬性,比如像淘寶這樣的在線購物網(wǎng)站,就要求7x24小時(shí)不間斷地對外提供服務(wù),而對于一致性,則更加是所有消費(fèi)者對于一個(gè)軟件的剛需。
因此,在可用性和一致性之間永遠(yuǎn)無法存在一個(gè)兩全其美的方案,于是如何構(gòu)建一個(gè)兼顧可用性和一致性的分布式系統(tǒng)成為了無數(shù)開發(fā)人員探討的難題,于是就出現(xiàn)了CAP和BASE這樣的分布式系統(tǒng)經(jīng)典理論
CAP定理
什么是CAP理論？
CAP理論告訴我們，一個(gè)分布式系統(tǒng)不可能同時(shí)滿足一致性(Consistency)、可用性(Avaliability)、分區(qū)容錯(cuò)性(Partition)這三分基本需求，最多只能同時(shí)滿足其中2兩個(gè)
| 一致性 | 分布式環(huán)境中，數(shù)據(jù)在多個(gè)副本之間能夠保持一致的特性(嚴(yán)格一致性)，在一致性的需求下，當(dāng)一個(gè)系統(tǒng)在數(shù)據(jù)一致性的狀態(tài)下執(zhí)行更新操作后，應(yīng)該保證系統(tǒng)的數(shù)據(jù)依然處在一直的轉(zhuǎn)態(tài) |
| 可用性 | 系統(tǒng)提供的服務(wù)必須一直處于可用的狀態(tài)，每次請求都能獲取到非錯(cuò)的響應(yīng)–但不保證獲取的數(shù)據(jù)為最新數(shù)據(jù) |
| 分區(qū)容錯(cuò)性 | 分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時(shí)候，依然能夠?qū)ν馓峁?strong>滿足一致性和可用性的服務(wù)，除非整個(gè)網(wǎng)絡(luò)環(huán)境都發(fā)生了故障 |
為什么只能3選2
首先，能不能同事滿足這三個(gè)條件？
假設(shè)有一個(gè)系統(tǒng)如下：
整個(gè)系統(tǒng)由兩個(gè)節(jié)點(diǎn)配合組成，之間通過網(wǎng)絡(luò)通信，當(dāng)節(jié)點(diǎn)A進(jìn)行更新數(shù)據(jù)庫操作的時(shí)候，需要同時(shí)更新節(jié)點(diǎn)B的數(shù)據(jù)庫(這是一個(gè)原子操作)
上面這個(gè)系統(tǒng)怎么滿足CAP呢？C(一致性)：當(dāng)節(jié)點(diǎn)A更新的時(shí)候，節(jié)點(diǎn)B也要更新， A(可用性)：必須保證兩個(gè)節(jié)點(diǎn)都是可用的， P(網(wǎng)絡(luò)分區(qū):由于網(wǎng)絡(luò)故障導(dǎo)致各個(gè)機(jī)器不能通訊，又可能其他機(jī)器又在通信，這樣就造成了網(wǎng)絡(luò)劃分成多個(gè)子網(wǎng)絡(luò))當(dāng)節(jié)點(diǎn)A、B出現(xiàn)了網(wǎng)絡(luò)分區(qū)，必須保證對外可用。
可見，根本完成不了同時(shí)滿足CAP，因?yàn)?strong>只要出現(xiàn)了網(wǎng)絡(luò)分區(qū)，C就無法滿足，因?yàn)楣?jié)點(diǎn)A根本連接不上節(jié)點(diǎn)B。如果強(qiáng)行滿足C一致性，就必須停止服務(wù)運(yùn)行，從而放棄可用性A
所以，最多滿足兩個(gè)條件：
| CA(一致性+可用性) | 放棄分區(qū)容錯(cuò)性，說白了，就是一個(gè)整體的應(yīng)用，如果希望能夠避免系統(tǒng)出現(xiàn)分區(qū)容錯(cuò)性問題，一種較為簡單的做法是將所有的數(shù)據(jù)(或者僅僅是那些與事務(wù)相關(guān)的數(shù)據(jù))都放在一個(gè)分布式節(jié)點(diǎn)上。這樣做雖然無法100%保證系統(tǒng)不會(huì)出錯(cuò)，但至少不會(huì)碰到由于網(wǎng)絡(luò)分區(qū)帶來的負(fù)面影響。但同時(shí)需要注意的是，放棄P的同時(shí)也就意味著放棄了系統(tǒng)的可拓展性 |
| CP(一致性+分區(qū)容錯(cuò)性) | 一旦系統(tǒng)遇到網(wǎng)絡(luò)分區(qū)或其它故障或?yàn)榱吮ＷC一致性時(shí)，放棄可用性，那么受到影響的服務(wù)需要等待一定的時(shí)間需要等網(wǎng)絡(luò)修復(fù)好以后才能繼續(xù)提供服務(wù)，因此在等待期間系統(tǒng)無法對外提供正常的服務(wù)，即不可用 |
| AP(可用性+分區(qū)容錯(cuò)性) | 出現(xiàn)網(wǎng)絡(luò)分區(qū)，為了保證可用性，必須讓節(jié)點(diǎn)繼續(xù)對外提供服務(wù)，這樣必然失去一致性。這里所說的放棄一致性，并不是完全不需要數(shù)據(jù)一致性，指的是放棄系統(tǒng)的強(qiáng)一致性，保留最終一致性。這樣的系統(tǒng)無法保證數(shù)據(jù)保持實(shí)時(shí)的一致性，但是能夠承諾的是，數(shù)據(jù)最終會(huì)達(dá)到一個(gè)一致的狀態(tài)這就引入了一個(gè)時(shí)間窗口的概念，具體多久能夠達(dá)到數(shù)據(jù)一致性的狀態(tài)取決于系統(tǒng)的設(shè)計(jì)，主要包括數(shù)據(jù)副本在不同節(jié)點(diǎn)之間的復(fù)制時(shí)間長短。 |
能不能解決3選2的問題
想要解決3選2的問題，首先大家需要思考分區(qū)是100%出現(xiàn)的？如果不出現(xiàn)分區(qū),那么就能夠同時(shí)滿足CAP。如果出現(xiàn)了分區(qū)，可以根據(jù)策略進(jìn)行調(diào)整。比如C不必使用那么強(qiáng)的一致性，可以先將數(shù)據(jù)存在一起，稍后再更新，實(shí)現(xiàn)所謂的"最終一致性"
基于這個(gè)思路，引出了第二個(gè)理論Base理論
BASE理論
什么是BASE理論？
BASE：全稱：Basically Available(基本可用)，Soft state(軟狀態(tài))，和Eventually consistent（最終一致性）三個(gè)短語的縮寫，來自eBay架構(gòu)師提出。
Base理論是對CAP中一致性和可用性權(quán)衡的結(jié)果，其來源于對大型互聯(lián)網(wǎng)分布式實(shí)踐的總結(jié)，是基于CAP定理逐步演化而來的。
其核心思想：既然無法做到強(qiáng)一致性(String consistency)，但每個(gè)應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達(dá)到最終一致性(Eventual consistency )
Basically Available（基本可用）
什么是基本可用呢？
基本可用是指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時(shí)候，允許損失部門可用性-但不等于系統(tǒng)不可用。以下就是兩個(gè)“基本可用”的例子
一致性協(xié)議2PC
為了使系統(tǒng)盡量能夠達(dá)到CAP，于是有了BASE協(xié)議，而BASE協(xié)議是在可用性和一致性之間做的取舍和妥協(xié)。
也就是說，我們在對分布式系統(tǒng)進(jìn)行架構(gòu)設(shè)計(jì)的過程中，往往需要我們在系統(tǒng)的可用性和數(shù)據(jù)一致性之間反復(fù)的權(quán)衡。于是，就涌現(xiàn)了許多經(jīng)典的算法和協(xié)議，最著名的幾種就是二階段提交協(xié)議、三階段提交協(xié)Paxos算法等。
什么是2PC？
在分布式系統(tǒng)中，會(huì)有多個(gè)機(jī)器節(jié)點(diǎn)，每一個(gè)機(jī)器節(jié)點(diǎn)雖然能夠明確地知道自己在進(jìn)行事務(wù)操作過程中的結(jié)果是成功或失敗，但無法直接獲取到其他分布式節(jié)點(diǎn)的操作結(jié)果，因此當(dāng)一個(gè)事務(wù)操作需要跨越多個(gè)分布式節(jié)點(diǎn)的時(shí)候，為了保證事務(wù)處理的ACID特性，就需要引入一個(gè)“協(xié)調(diào)者”的組件來統(tǒng)一調(diào)度所有分布式節(jié)點(diǎn)的執(zhí)行邏輯，這些被調(diào)度的節(jié)點(diǎn)則稱為“參與者”，協(xié)調(diào)者負(fù)責(zé)調(diào)度參與者的行為，并最終決定這些參與者是否要把事務(wù)真正進(jìn)行提交。基于這個(gè)思想，就衍生了二階段提交和三階段提交兩種協(xié)議。
協(xié)議說明：
二階段提交就是將事務(wù)的提交過程分成了兩個(gè)階段來進(jìn)行處理，流程如下：
階段一：提交事務(wù)請求
1.事務(wù)詢問
協(xié)調(diào)者向所有的參與者發(fā)送事務(wù)內(nèi)容，詢問是否可以執(zhí)行事務(wù)提交操作，并開始等待其他參與者的響應(yīng)。
2.執(zhí)行事務(wù)
各參與者節(jié)點(diǎn)執(zhí)行事務(wù)操作，并將Undo和Redo信息記入事務(wù)日志中(Undo能保證事務(wù)的一致性，Redo用來保證事務(wù)的原子性和持久性，兩者也是系統(tǒng)恢復(fù)的基礎(chǔ)前提)
3.各參與者向協(xié)調(diào)者反饋事務(wù)詢問的響應(yīng)
如果參與者成功執(zhí)行了事務(wù)操作，那么就反饋給協(xié)調(diào)者Yes響應(yīng)，表示事務(wù)可以執(zhí)行；如果參與者沒有成功執(zhí)行事務(wù)，就返回No給協(xié)調(diào)者，表示事務(wù)不可以執(zhí)行。
由于上面的內(nèi)容在形式上近似是協(xié)調(diào)者組織各參與者對一次事務(wù)操作的投票表態(tài)過程，因此二階段提交協(xié)議的階段一也被稱為“投票階段”，即各參與者投票表明是否要繼續(xù)執(zhí)行接下去的事務(wù)提交操作。
階段二：執(zhí)行事務(wù)提交
在階段二中，就會(huì)根據(jù)階段一的投票結(jié)果來決定最終是否可以進(jìn)行事務(wù)提交操作，正常情況下，包含兩種操作可能：提交事務(wù)、中斷事務(wù)。
提交事務(wù)步驟如下：
假如協(xié)調(diào)者從所有的參與者獲得的反饋都是yes響應(yīng)，那么就會(huì)執(zhí)行事務(wù)提交。
1.發(fā)送提交請求
協(xié)調(diào)者向所有參與者發(fā)出commit請求。
2.事務(wù)提交
參與者收到commit請求后，會(huì)正式執(zhí)行事務(wù)提交操作，并在完成提交之后釋放整個(gè)事務(wù)執(zhí)行期間占用的事務(wù)資源。
3.反饋事務(wù)提交結(jié)果
參與者在完成事務(wù)提交之后，向協(xié)調(diào)者發(fā)送ACK信息。
4.完成事務(wù)
協(xié)調(diào)者接收到所有參與者反饋的ACK信息后，完成事務(wù)。
ACK：ACK字符是一些通信協(xié)議下用來做確認(rèn)消息的字符，也有通信協(xié)議使用其他字符。
中斷事務(wù)步驟如下：
假如任何一個(gè)參與者向協(xié)調(diào)者反饋了No響應(yīng)，或者在等待超時(shí)之后，協(xié)調(diào)者尚無法接受到所有參與者的反饋響應(yīng)，那么就會(huì)中斷事務(wù)。
1.發(fā)送事務(wù)回滾請求
協(xié)調(diào)者向所有參與者發(fā)出Rollback請求。
2.事務(wù)回滾
參與者接受到Rollback請求后，會(huì)利用其在階段一記錄的Undo記錄來執(zhí)行事務(wù)回滾操作，并在完成回滾之后釋放在整個(gè)事務(wù)執(zhí)行期間占用的資源。
3.反饋事務(wù)回滾結(jié)果
參與者在完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送ACK信息。
4.中斷事務(wù)
協(xié)調(diào)者接收到所有參與者反饋的ACK信息后，完成事務(wù)中斷。
從上面邏輯可以看出，二階段提交就做了兩件事情：投票、執(zhí)行。
2PC優(yōu)缺點(diǎn)
優(yōu)點(diǎn)
原理簡單，實(shí)現(xiàn)方便
缺點(diǎn)
同步阻塞，單點(diǎn)問題數(shù)據(jù)不一致，過于保守
擴(kuò)展討論
網(wǎng)絡(luò)中存在各種不確定性，其中協(xié)議流程是基于時(shí)間順序的（時(shí)間），而協(xié)議又涉及到不同的參與者（空間），時(shí)空交錯(cuò)，任一點(diǎn)都有可能出現(xiàn)意外，因此我們可以通過時(shí)間和空間對協(xié)議流程進(jìn)行展開討論：
階段一：協(xié)調(diào)者出問題、參與者正常
假設(shè)只有部分節(jié)點(diǎn)收到協(xié)調(diào)者的詢問并給予協(xié)調(diào)者反饋了，協(xié)調(diào)者此時(shí)除了問題，無法繼續(xù)詢問，這些部分已經(jīng)參與詢問的參與者可以放棄事務(wù)，相當(dāng)于全局事務(wù)回滾。
階段一：協(xié)調(diào)者正常、部分參與者出問題
假設(shè)有一部分參與者不可用，表現(xiàn)為無法響應(yīng)或者響應(yīng)No，協(xié)調(diào)者知道這件事情，因此可以通知其他參與者放棄事務(wù)，同時(shí)其他事務(wù)也可以自行放棄事務(wù)，相當(dāng)于全局事務(wù)回滾。
階段一：協(xié)調(diào)者和參與者都出問題
假設(shè)部分正常的參與者如果接受過詢問，此時(shí)協(xié)調(diào)者出問題了，其他部分參與者也出問題了，則正常已經(jīng)參與過詢問的參與者可以放棄事務(wù)，相當(dāng)于全局事務(wù)回滾。
階段二：協(xié)調(diào)者出問題、參與者正常；
假設(shè)進(jìn)入第二階段，部分參與者已經(jīng)提交了，此時(shí)協(xié)調(diào)者出問題了，此時(shí)部分提交的參與者，造成了全局狀態(tài)的不一致的問題。
階段二：協(xié)調(diào)者正常、參與者出問題
假設(shè)進(jìn)入第二階段，協(xié)調(diào)者通知完部分參與者提交了之后發(fā)現(xiàn)另一部分參與者不可用，此時(shí)一部分參與者已經(jīng)提交了，造成了全局狀態(tài)的不一致問題。
階段二：協(xié)調(diào)者和參與者都出問題
此時(shí)部分提交的事務(wù)仍然造成了全局狀態(tài)的不一致。
上面可以看出在2PC進(jìn)入第二階段之后，無論是協(xié)調(diào)者出問題還是參與者出問題，都會(huì)造成全局資源狀態(tài)的不一致問題，那么為什么會(huì)造成這種問題呢？比如協(xié)調(diào)者出問題了、部分參與者已經(jīng)提交的情況，其余未提交的參與者并不知道這部分已經(jīng)提交的參與者是什么狀況，因?yàn)閷τ谶@部分未提交的參與者來說，協(xié)調(diào)者已經(jīng)跪了，它們無法知道全局事務(wù)的狀態(tài)，而且剩下的參與者的狀況有以下三種可能：
因?yàn)橛刑嗖淮_定性，因此對于這部分未提交的參與者來說什么都不能做，因?yàn)樽鍪裁炊际清e(cuò)的，結(jié)果就是出現(xiàn)了全局狀態(tài)的一致性問題，那么從這個(gè)角度上來講，三階段提交協(xié)議減少這種不確定性，后面會(huì)講到。
- 同步阻塞：
二階段提交協(xié)議存在最明顯也是最大的一個(gè)問題就是同步阻塞，在二階段提交的執(zhí)行過程中，所有參與該事務(wù)操作的邏輯都處于阻塞狀態(tài)，也就是說，各個(gè)參與者在等待其他參與者響應(yīng)的過程中，無法進(jìn)行其他操作。這種同步阻塞極大的限制了分布式系統(tǒng)的性能。 - 單點(diǎn)問題：
協(xié)調(diào)者在整個(gè)二階段提交過程中很重要，如果協(xié)調(diào)者在提交階段出現(xiàn)問題，那么整個(gè)流程將無法運(yùn)轉(zhuǎn)，更重要的是：其他參與者將會(huì)處于一直鎖定事務(wù)資源的狀態(tài)中，而無法繼續(xù)完成事務(wù)操作。 - 數(shù)據(jù)不一致：
假設(shè)當(dāng)協(xié)調(diào)者向所有的參與者發(fā)送commit請求之后，發(fā)生了局部網(wǎng)絡(luò)異常或者是協(xié)調(diào)者在尚未發(fā)送完所有commit請求之前自身發(fā)生了崩潰，導(dǎo)致最終只有部分參與者收到了commit請求。這將導(dǎo)致嚴(yán)重的數(shù)據(jù)不一致問題。 - 過于保守：
如果在二階段提交的提交詢問階段中，參與者出現(xiàn)故障而導(dǎo)致協(xié)調(diào)者始終無法獲取到所有參與者的響應(yīng)信息的話，這時(shí)協(xié)調(diào)者只能依靠其自身的超時(shí)機(jī)制來判斷是否需要中斷事務(wù)，顯然，這種策略過于保守。btw，二階段提交協(xié)議沒有設(shè)計(jì)較為完善的容錯(cuò)機(jī)制，任意一個(gè)階段失敗都會(huì)導(dǎo)致整個(gè)事務(wù)的失敗。
(202001430繼續(xù)更新)
一致性協(xié)議3PC
剛剛講解了二階段提交協(xié)議的設(shè)計(jì)和實(shí)現(xiàn)原理，并明確指出了其在實(shí)際運(yùn)行過程中可能存在的諸如同步阻塞，單點(diǎn)問題，數(shù)據(jù)不一致，過于保守的容錯(cuò)機(jī)制等缺陷
而為了彌補(bǔ)二階段提交的缺點(diǎn)，引入了三階段提交協(xié)議。
什么是三階段提交
將2PC的“提交事務(wù)請求”過程一分為二，共形成了由CanCommit、PreCommit和doCommit三個(gè)階段組成的事務(wù)處理協(xié)議。
階段一：CanCommit
協(xié)調(diào)者向所有的參與者發(fā)送一個(gè)包含事務(wù)內(nèi)容的CanCommit請求，詢問是否可以執(zhí)行事務(wù)提交操作，并等待各參與者響應(yīng)
參與者在接收到來自協(xié)調(diào)者的包含事務(wù)內(nèi)容的canCommit請求后，判斷可以提交任務(wù)了返回Yes響應(yīng)，否則No
階段二：PreCommit
兩種情況：
????成功：執(zhí)行事務(wù)預(yù)提交
????失敗：中斷事務(wù)
發(fā)送預(yù)提交請求
協(xié)調(diào)者向所有參與者發(fā)出PreCommit請求，進(jìn)入準(zhǔn)備階段
事務(wù)預(yù)提交
參與者收到請求后，執(zhí)行事務(wù)操作，并將Undo、Redo信息記錄到事務(wù)日志中(改日志信息可以用來回滾事務(wù))
反饋執(zhí)行結(jié)果
協(xié)調(diào)者收到反饋，確定是提交(發(fā)送doCommit請求)還是終止(發(fā)送abort請求)操作。
階段三：doCommit
提交事務(wù)(收到doCommit請求將預(yù)提交狀態(tài)->提交狀態(tài))、中斷事務(wù)(收到abort請求)，完成事務(wù)以后發(fā)送ACK給協(xié)調(diào)者。
2pc和3pc對比：
優(yōu)點(diǎn)：
在2pc基礎(chǔ)上有協(xié)調(diào)者新增了一個(gè)CanCommit階段，會(huì)預(yù)先判斷機(jī)器是否可以執(zhí)行事務(wù)操作，而不是直接發(fā)送執(zhí)行事務(wù)操作請求，這樣做的優(yōu)點(diǎn)是降低了參與者的阻塞范圍(由于2pc是直接發(fā)送prepare，等待參與者事務(wù)處理完成并反饋結(jié)果)，其次能夠在單點(diǎn)故障后達(dá)成一致（由于第一階段是判斷服務(wù)器是否能夠CanCommit，協(xié)調(diào)者會(huì)根據(jù)反饋結(jié)果判斷有故障節(jié)點(diǎn)情況下，發(fā)送事務(wù)prepareCommit請求操作）
缺點(diǎn)：
如果參與者收到了PreCommit消息后，出現(xiàn)了網(wǎng)絡(luò)分區(qū)，此時(shí)協(xié)調(diào)者和參與者無法通信，參與者等待超時(shí)后，會(huì)進(jìn)行事務(wù)的提交(這種超時(shí)自動(dòng)提交機(jī)制是3pc特性，就是為了解決同步阻塞情況)，這必然出現(xiàn)分布式數(shù)據(jù)不一致問題
首先對于協(xié)調(diào)者和參與者都設(shè)置了超時(shí)機(jī)制(在2pc中，只有協(xié)調(diào)者擁有超時(shí)機(jī)制，即如果在一定時(shí)間內(nèi)沒有收到參與者的消息則默認(rèn)失敗)。其次在2pc的準(zhǔn)備階段和提交階段之間，插入預(yù)提交階段，這個(gè)階段是一個(gè)緩沖，保證了在最后提交之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。
一致性算法Paxos
paxos算法需要解決的是如何在發(fā)送機(jī)器宕機(jī)、網(wǎng)絡(luò)異常等異常的分布式系統(tǒng)中，快速且正確地在集群內(nèi)部對某個(gè)數(shù)據(jù)的值(不單是某個(gè)數(shù)，可表示一條日志、命令等)達(dá)成一致，并且保證不論發(fā)生任何異常都不會(huì)破壞整個(gè)系統(tǒng)的一致性
背景
相關(guān)概念
問題描述
推導(dǎo)過程
paxos算法描述
如何保證paxos算法的活性
一致性算法Raft
分布式系統(tǒng)設(shè)計(jì)策略
心跳檢測
高可用設(shè)計(jì)
容錯(cuò)性
負(fù)載均衡
分布式架構(gòu)網(wǎng)絡(luò)通信
基本概念
什么是RPC
RMI
BIO、NIO、AIO
Netty
IO編程
NIO編程
Netty編程
基于Netty自定義RPC
在基于教案的理解基礎(chǔ)上純手打有點(diǎn)浪費(fèi)時(shí)間，明天繼續(xù)補(bǔ)充！！
總結(jié)
- 上一篇： 从框架源码中学习结构型设计模式
- 下一篇： lucene分布式索引