1 分布式架構(gòu)詳解

1.1 分布式發(fā)展歷程

1.1.1 單點集中式

????????特點：App、DB、FileServer都部署在一臺機器上。并且訪問請求量較少

1.1.2? 應用服務和數(shù)據(jù)服務拆分

?特點：App、DB、FileServer分別部署在獨立服務器上。并且訪問請求量較少

1.1.3? 使用緩存改善性能

?特點：數(shù)據(jù)庫中頻繁訪問的數(shù)據(jù)存儲在緩存服務器中，減少數(shù)據(jù)庫的訪問次數(shù)，降低數(shù)據(jù)庫的壓力

1.1.4 應用服務器集群

?特點：多臺應用服務器通過負載均衡同時對外提供服務，解決單臺服務器處理能力上限的問題

1.1.5 數(shù)據(jù)庫讀寫分離

?特點：數(shù)據(jù)庫進行讀寫分離（主從）設(shè)計，解決數(shù)據(jù)庫的處理壓力

1.1.6 反向代理和CDN加速

?特點：采用反向代理和CDN加快系統(tǒng)的訪問速度

1.1.7 分布式文件系統(tǒng)和分布式數(shù)據(jù)庫

?特點：數(shù)據(jù)庫采用分布式數(shù)據(jù)庫，文件系統(tǒng)采用分布式文件系統(tǒng)

????????隨著業(yè)務的發(fā)展，最終數(shù)據(jù)庫讀寫分離也將無法滿足需求，需要采用分布式數(shù)據(jù)庫和分布式文件系統(tǒng)來支撐。

????????分布式數(shù)據(jù)庫是數(shù)據(jù)庫拆分后的最后方法，只有在單表規(guī)模非常龐大的時候才使用，更常用的數(shù)據(jù)庫拆分手段是業(yè)務分庫，將不同業(yè)務的數(shù)據(jù)庫部署在不同的機器上

1.2?分布式技術(shù)詳解

1. 并發(fā)性

2. 分布性

　　大任務拆分成多個任務部署到多臺機器上對外提供服務

3. 缺乏全局時鐘 ?

　　時間要統(tǒng)一

4. 對等性

　　一個服務部署在多臺機器上是一樣的，無任何差別

5. 故障肯定會發(fā)生

　　?硬盤壞了 CPU燒了....

1.3 分布式事務

1.3.1 ACID

• 原子性（Atomicity）：一個事務（transaction）中的所有操作，要么全部完成，要么全部不完成，不會結(jié)束在中間某個環(huán)節(jié)。事務在執(zhí)行過程中發(fā)生錯誤，會被恢復（Rollback）到事務開始前的狀態(tài)，就像這個事務從來沒有執(zhí)行過一樣。
• 一致性（Consistency）：在事務開始之前和事務結(jié)束以后，數(shù)據(jù)庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預設(shè)規(guī)則，這包含資料的精確度、串聯(lián)性以及后續(xù)數(shù)據(jù)庫可以自發(fā)性地完成預定的工作。比如A有500元，B有300元，A向B轉(zhuǎn)賬100，無論怎么樣，A和B的總和總是800元。
• 隔離性（Isolation）：數(shù)據(jù)庫允許多個并發(fā)事務同時對其數(shù)據(jù)進行讀寫和修改的能力，隔離性可以防止多個事務并發(fā)執(zhí)行時由于交叉執(zhí)行而導致數(shù)據(jù)的不一致。事務隔離分為不同級別，包括讀未提交（Read uncommitted）、讀提交（read committed）、可重復讀（repeatable read）和串行化（Serializable）。
• 持久性（Durability）：事務處理結(jié)束后，對數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會丟失。

1.3.2 2P/3P

• 2P= Two Phase commit ??二段提交（RDBMS（關(guān)系型數(shù)據(jù)庫管理系統(tǒng)）經(jīng)常就是這種機制，保證強一致性）
• 3P= Three Phase commit ?三段提交

說明：2P/3P是為了保證事務的ACID（原子性、一致性、隔離性、持久性）

1.3.2.1 2P的兩個階段

????????階段1：提交事務請求（投票階段）詢問是否可以提交事務。

????????階段2：執(zhí)行事務提交（commit、rollback）?真正的提交事務。

1.3.2.2 3P的三個階段

1. 階段1：是否提交-詢問是否可以做事務提交
2. 階段2：預先提交-預先提交事務
3. 階段3：執(zhí)行事務提交（commit、rollback）真正的提交事務

說明：3P把2P的階段一拆分成了前面兩個階段

1.3.3 CAP理論

• 一致性（Consistency）：分布式數(shù)據(jù)庫的數(shù)據(jù)保持一致
• 可用性（Availability）：任何一個節(jié)點掛了，其他節(jié)點可以繼續(xù)對外提供服務
• 分區(qū)容錯性（網(wǎng)絡(luò)分區(qū)）Partition tolerance：一個數(shù)據(jù)庫所在的機器壞了，如硬盤壞了，數(shù)據(jù)丟失了，可以新增一臺機器，然后從其他正常的機器把備份的數(shù)據(jù)同步過來

????????CAP理論的特點：CAP只能滿足其中2條

• CA(放棄P)：將所有的數(shù)據(jù)放在一個節(jié)點。滿足一致性、可用性。
• AP(放棄C)：放棄強一致性，用最終一致性來保證。
• CP(放棄A)：一旦系統(tǒng)遇見故障，受到影響的服務器需要等待一段時間，在恢復期間無法對外提供服務。

舉例說明CAP理論：

????????有3臺機器分別有3個數(shù)據(jù)庫分別有兩張表,數(shù)據(jù)都是一樣的：

Machine1-db1-tbl_person、tbl_order

Machine2-db2-tbl_person、tbl_order

Machine3-db3-tbl_person、tbl_order

????????1）當向machine1的db1的表tbl_person、tbl_order插入數(shù)數(shù)據(jù)時，同時要把插入的數(shù)據(jù)同步到machine2、machine3，這就是一致性

????????2）當其中的一臺機器宕機了，可以繼續(xù)對外提供服務，把宕機的機器重新啟動起來可以繼續(xù)服務，這就是可用性

????????3）當machine1的機器壞了，數(shù)據(jù)全部丟失了，不會有任何問題，因為machine2和machine3上還有數(shù)據(jù)，重新加一臺機器machine4，把machine2和machine3其中一臺機器的備份數(shù)據(jù)同步過來就可以了，這就是分區(qū)容錯性

1.3.4 BASE理論

????????基本可用（bascially available）、軟狀態(tài)（soft state）、最終一致性（Eventually consistent）：

• 基本可用：在分布式系統(tǒng)出現(xiàn)故障，允許損失部分可用性（服務降級、頁面降級）
• 軟狀態(tài)：允許分布式系統(tǒng)出現(xiàn)中間狀態(tài)。而且中間狀態(tài)不影響系統(tǒng)的可用性。
• 　　　　這里的中間狀態(tài)是指不同的data replication之間的數(shù)據(jù)更新可以出現(xiàn)延時的最終一致性

　　如CAP理論里面的示例，當向machine1的db1的表tbl_person、tbl_order插入數(shù)數(shù)據(jù)時，同時要把插入的數(shù)據(jù)同步到machine2、machine3，當machine3的網(wǎng)絡(luò)有問題時，同步失敗，但是過一會網(wǎng)絡(luò)恢復了就同步成功了，這個同步失敗的狀態(tài)就稱為軟狀態(tài)，因為最終還是同步成功了。

• 最終一致性：data replications經(jīng)過一段時間達到一致性。

1.3.5 Paxos算法

1.3.5.1 介紹Paxos算法之前我們先來看一個小故事

• 拜占庭將軍問題

　　拜占庭帝國就是5~15世紀的東羅馬帝國，拜占庭即現(xiàn)在土耳其的伊斯坦布爾。我們可以想象，拜占庭軍隊有許多分支，駐扎在敵人城外，每一分支由各自的將軍指揮。假設(shè)有11位將軍，將軍們只能靠通訊員進行通訊。在觀察敵人以后，忠誠的將軍們必須制訂一個統(tǒng)一的行動計劃——進攻或者撤退。然而，這些將軍里有叛徒，他們不希望忠誠的將軍們能達成一致，因而影響統(tǒng)一行動計劃的制訂與傳播。

　　問題是：將軍們必須有一個協(xié)議，使所有忠誠的將軍們能夠達成一致，而且少數(shù)幾個叛徒不能使忠誠的將軍們作出錯誤的計劃——使有些將軍進攻而另一些將軍撤退。

　　假設(shè)有9位忠誠的將軍，5位判斷進攻，4位判斷撤退，還有2個間諜惡意判斷撤退，雖然結(jié)果是錯誤的撤退，但這種情況完全是允許的。因為這11位將軍依然保持著狀態(tài)一致性。

總結(jié)：

1）11位將軍進攻城池

2）同時進攻（議案、決議）、同時撤退（議案、決議）

3）不管撤退還是進攻，必須半數(shù)的將軍統(tǒng)一意見才可以執(zhí)行

4）將軍里面有叛徒，會干擾決議生成

1.3.5.2 下面就來介紹一下Paxos算法

????????Google Chubby的作者Mike Burrows說過這個世界上只有一種一致性算法，那就是Paxos，其它的算法都是殘次品。?

Paxos：多數(shù)派決議（最終解決一致性問題）

????????Paxos算法有三種角色：Proposer，Acceptor，Learner

• Proposer：提交者（議案提交者），提交議案(判斷是否過半)，提交批準議案(判斷是否過半)
• Acceptor：接收者（議案接收者），接受議案或者駁回議案，給proposer回應(promise)
• Learner：學習者（打醬油的）

?????????如果議案產(chǎn)生，學習議案。

設(shè)定1：如果Acceptor沒有接受議案，那么他必須接受第一個議案

設(shè)定2：每個議案必須有一個編號，并且編號只能增長，不能重復。越往后越大。

設(shè)定3：接受編號大的議案，如果小于之前接受議案編號，那么不接受

設(shè)定4：議案有2種(提交的議案，批準的議案)

1）Prepare階段（議案提交）

????????a）Proposer希望議案V。首先發(fā)出Prepare請求至大多數(shù)Acceptor。Prepare請求內(nèi)容為序列號K

????????b）Acceptor收到Prepare請求為編號K后，檢查自己手里是否有處理過Prepare請求。

????????c）如果Acceptor沒有接受過任何Prepare請求，那么用OK來回復Proposer，代表Acceptor必須接受收到的第一個議案（設(shè)定1）

????????d）否則，如果Acceptor之前接受過任何Prepare請求（如：MaxN），那么比較議案編號，如果K

????????e）如果K>=MaxN，那么檢查之前是否有批準的議案，如果沒有則用OK來回復Proposer，并記錄K

????????f）如果K>=MaxN，那么檢查之前是否有批準的議案，如果有則回復批準的議案編號和議案內(nèi)容（如：， AcceptN為批準的議案編號，AcceptV為批準的議案內(nèi)容）

2）Accept階段（批準階段）

????????a）Proposer收到過半Acceptor發(fā)來的回復，回復都是OK，且沒有附帶任何批準過的議案編號和議案內(nèi)容。那么Proposer繼續(xù)提交批準請求，不過此時會連議案編號K和議案內(nèi)容V一起提交（這種數(shù)據(jù)形式）

????????b）Proposer收到過半Acceptor發(fā)來的回復，回復都是OK，且附帶批準過的議案編號和議案內(nèi)容（）。那么Proposer找到所有回復中超過半數(shù)的那個（假設(shè)為）作為提交批準請求（請求為）發(fā)送給Acceptor。

????????c）Proposer沒有收到過半Acceptor發(fā)來的回復，則修改議案編號K為K+1，并將編號重新發(fā)送給Acceptors（重復Prepare階段的過程）

????????d）Acceptor收到Proposer發(fā)來的Accept請求，如果編號K

????????e）Acceptor收到Proposer發(fā)來的Accept請求，如果編號K>=MaxN則批準該議案，并設(shè)置手里批準的議案為，回復Proposer。

????????f）經(jīng)過一段時間Proposer對比手里收到的Accept回復，如果超過半數(shù)，則結(jié)束流程（代表議案被批準），同時通知Leaner可以學習議案。

????????g) 經(jīng)過一段時間Proposer對比手里收到的Accept回復，如果未超過半數(shù)，則修改議案編號重新進入Prepare階段。

1.3.5.3 Paxos示例

1.3.5.3.1 示例1：先后提議的場景

角色：

• proposer：參謀1，參謀2
• acceptor：將軍1，將軍2，將軍3（決策者）

1）參謀1發(fā)起提議，派通信兵帶信給3個將軍，內(nèi)容為（編號1）；

2）3個將軍收到參謀1的提議，由于之前還沒有保存任何編號，因此把（編號1）保存下來，避免遺忘；同時讓通信兵帶信回去，內(nèi)容為（ok）；

3）參謀1收到至少2個將軍的回復，再次派通信兵帶信給3個將軍，內(nèi)容為（編號1，進攻時間1）；

4）3個將軍收到參謀1的時間，把（編號1，進攻時間1）保存下來，避免遺忘；同時讓通信兵帶信回去，內(nèi)容為（Accepted）；

5）參謀1收到至少2個將軍的（Accepted）內(nèi)容，確認進攻時間已經(jīng)被大家接收；

6）參謀2發(fā)起提議，派通信兵帶信給3個將軍，內(nèi)容為（編號2）；

7）3個將軍收到參謀2的提議，由于（編號2）比（編號1）大，因此把（編號2）保存下來，避免遺忘；又由于之前已經(jīng)接受參謀1的提議，因此讓通信兵帶信回去，內(nèi)容為（編 號1，進攻時間1）；

8）參謀2收到至少2個將軍的回復，由于回復中帶來了已接受的參謀1的提議內(nèi)容，參謀2因此不再提出新的進攻時間，接受參謀1提出的時間；

1.3.5.3.2 示例2：交叉場景

角色：

• proposer：參謀1，參謀2
• acceptor：將軍1，將軍2，將軍3（決策者）

1）參謀1發(fā)起提議，派通信兵帶信給3個將軍，內(nèi)容為（編號1）；

2）3個將軍的情況如下

　　a）將軍1和將軍2收到參謀1的提議，將軍1和將軍2把（編號1）記錄下來，如果有其他參謀提出更小的編號，將被拒絕；同時讓通信兵帶信回去，內(nèi)容為（ok）；

　　b）負責通知將軍3的通信兵被抓，因此將軍3沒收到參謀1的提議；

3）參謀2在同一時間也發(fā)起了提議，派通信兵帶信給3個將軍，內(nèi)容為（編號2）；

4）3個將軍的情況如下

　　a）將軍2和將軍3收到參謀2的提議，將軍2和將軍3把（編號2）記錄下來，如果有其他參謀提出更小的編號，將被拒絕；同時讓通信兵帶信回去，內(nèi)容為（ok）；

　　b）負責通知將軍1的通信兵被抓，因此將軍1沒收到參謀2的提議；

5）參謀1收到至少2個將軍的回復，再次派通信兵帶信給有答復的2個將軍，內(nèi)容為（編號1，進攻時間1）；

6）2個將軍的情況如下

　　a）將軍1收到了（編號1，進攻時間1），和自己保存的編號相同，因此把（編號1，進攻時間1）保存下來；同時讓通信兵帶信回去，內(nèi)容為（Accepted）；

　　b）將軍2收到了（編號1，進攻時間1），由于（編號1）小于已經(jīng)保存的（編號2），因此讓通信兵帶信回去，內(nèi)容為（Rejected，編號2）；

7）參謀2收到至少2個將軍的回復，再次派通信兵帶信給有答復的2個將軍，內(nèi)容為（編號2，進攻時間2）；

8）將軍2和將軍3收到了（編號2，進攻時間2），和自己保存的編號相同，因此把（編號2，進攻時間2）保存下來，同時讓通信兵帶信回去，內(nèi)容為（Accepted）；

9）參謀2收到至少2個將軍的（Accepted）內(nèi)容，確認進攻時間已經(jīng)被多數(shù)派接受；

10）參謀1只收到了1個將軍的（Accepted）內(nèi)容，同時收到一個（Rejected，編號2）；參謀1重新發(fā)起提議，派通信兵帶信給3個將軍，內(nèi)容為（編號3）；

11）3個將軍的情況如下

　　a）將軍1收到參謀1的提議，由于（編號3）大于之前保存的（編號1），因此把（編號3）保存下來；由于將軍1已經(jīng)接受參謀1前一次的提議，因此讓通信兵帶信回去，內(nèi)容為（編號1，進攻時間1）；

　　b）將軍2收到參謀1的提議，由于（編號3）大于之前保存的（編號2），因此把（編號3）保存下來；由于將軍2已經(jīng)接受參謀2的提議，因此讓通信兵帶信回去，內(nèi)容為（編號2，進攻時間2）；

　　c）負責通知將軍3的通信兵被抓，因此將軍3沒收到參謀1的提議；

12）參謀1收到了至少2個將軍的回復，比較兩個回復的編號大小，選擇大編號對應的進攻時間作為最新的提議；參謀1再次派通信兵帶信給有答復的2個將軍，內(nèi)容為（編號3，進攻時間2）；

13）將軍1和將軍2收到了（編號3，進攻時間2），和自己保存的編號相同，因此保存（編號3，進攻時間2），同時讓通信兵帶信回去，內(nèi)容為（Accepted）；

14）參謀1收到了至少2個將軍的（accepted）內(nèi)容，確認進攻時間已經(jīng)被多數(shù)派接受。

1.4 Zookeeper ZAB協(xié)議

????????Zookeeper Automic Broadcast(ZAB)，即Zookeeper原子性廣播，是Paxos經(jīng)典實現(xiàn)

術(shù)語：

????????quorum：集群過半數(shù)的集合

1.4.1 ZAB(zookeeper)中節(jié)點分四種狀態(tài)

• looking：選舉Leader的狀態(tài)（崩潰恢復狀態(tài)下）
• following：跟隨者（follower）的狀態(tài)，服從Leader命令
• leading：當前節(jié)點是Leader，負責協(xié)調(diào)工作。
• observing：observer(觀察者)，不參與選舉，只讀節(jié)點。

1.4.2?ZAB中的兩個模式（ZK是如何進行選舉的）

????????崩潰恢復、消息廣播

1.4.2.1 崩潰恢復

????????leader掛了，需要選舉新的leader

a.每個server都有一張選票，如（3,9），選票投自己。

b.每個server投完自己后，再分別投給其他還可用的服務器。如把Server3的（3,9）分別投給Server4和Server5，一次類推

c.比較投票，比較邏輯：優(yōu)先比較Zxid，Zxid相同時才比較myid。比較Zxid時，大的做leader；比較myid時，小的做leader

d.改變服務器狀態(tài)（崩潰恢復->數(shù)據(jù)同步，或者崩潰恢復->消息廣播）

相關(guān)概念補充說明：

• epoch：周期值
• acceptedEpoch（比喻：年號）：follower已經(jīng)接受leader更改年號的（newepoch）提議。
• currentEpoch（比喻：當前的年號）：當前的年號
• lastZxid：history中最近接收到的提議zxid(最大的值)
• history：當前節(jié)點接受到事務提議的log

Zxid數(shù)據(jù)結(jié)構(gòu)說明：

cZxid = 0x10000001b

64位的數(shù)據(jù)結(jié)構(gòu)

高32位：10000

　　　　Leader的周期編號+myid的組合

低32位：001b

　　　　事務的自增序列（單調(diào)遞增的序列）只要客戶端有請求，就+1

當產(chǎn)生新Leader的時候，就從這個Leader服務器上取出本地log中最大事務Zxid，從里面讀出epoch+1，作為一個新epoch，并將低32位置0（保證id絕對自增）

1.4.2.2 消息廣播（類似2P提交）

1. Leader接受請求后，將這個請求賦予全局的唯一64位自增Id（zxid）。
2. 將zxid作為議案發(fā)給所有follower。
3. 所有的follower接受到議案后，想將議案寫入硬盤后，馬上回復Leader一個ACK（OK）。
4. 當Leader接受到合法數(shù)量（過半）Acks，Leader給所有follower發(fā)送commit命令。
5. follower執(zhí)行commit命令。

注意：到了這個階段，ZK集群才正式對外提供服務，并且Leader可以進行消息廣播，如果有新節(jié)點加入，還需要進行同步。

1.4.2.3 數(shù)據(jù)同步

1. 取出Leader最大lastZxid（從本地log日志來）
2. 找到對應zxid的數(shù)據(jù)，進行同步（數(shù)據(jù)同步過程保證所有follower一致）
3. 只有滿足quorum同步完成，準Leader才能成為真正的Leader

參考鏈接

Zookeeper系列二：分布式架構(gòu)詳解、分布式技術(shù)詳解、分布式事務?

隨筆分類?-??Zookeeper專題系列

Zookeeper簡介及核心概念_Cynicism_Kevin的博客-CSDN博客

zookeeper安裝以及使用_燕少?江湖的博客-CSDN博客

Zookeeper工作原理（詳細）_zookeeper原理_筆墨登場說說的博客-CSDN博客

Zookeeper的功能以及工作原理_zookeeper的主要功能_空白格的空白的博客-CSDN博客

ZooKeeper基本原理

深入了解Zookeeper核心原理

Zookeeper原理解析 - 簡書

zookeeper的領(lǐng)導者選舉和原子廣播 - lpshou - 博客園

Zookeeper原理詳解_百里度的博客-CSDN博客

Zookeeper學習系列【三】Zookeeper 集群架構(gòu)、讀寫機制以及一致性原理(ZAB協(xié)議) - 掘金

從背景到原理，到架構(gòu)體系，粉碎Zookeeper面試連環(huán)炮 - 掘金