一、分散式架構詳解

1、分散式發展歷程

1.1 單點集中式

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

1.2  應用服務和資料服務拆分

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

1.3  使用快取改善效能

 特點：資料庫中頻繁訪問的資料儲存在快取伺服器中，減少資料庫的訪問次數，降低資料庫的壓力

1.4 應用伺服器叢集

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

1.5 資料庫讀寫分離

特點：

資料庫進行讀寫分離（主從）設計，解決資料庫的處理壓力

1.6 反向代理和CDN加速

 特點：採用反向代理和CDN加快系統的訪問速度

1.7 分散式檔案系統和分散式資料庫

 特點：資料庫採用分散式資料庫，檔案系統採用分散式檔案系統

隨著業務的發展，最終資料庫讀寫分離也將無法滿足需求，需要採用分散式資料庫和分散式檔案系統來支撐

分散式資料庫是資料庫拆分後的最後方法，只有在單表規模非常龐大的時候才使用，更常用的資料庫拆分手段是業務分庫，將不同業務的資料庫部署在不同的機器上

二、 分散式技術詳解

1. 併發性

2. 分佈性

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

3. 缺乏全域性時鐘  

　　時間要統一

4. 對等性

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

5. 故障肯定會發生

　　 硬碟壞了 CPU燒了....

三、分散式事務

1. ACID

原子性（Atomicity）：一個事務（transaction）中的所有操作，要麼全部完成，要麼全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被恢復（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。

一致性（Consistency）：在事務開始之前和事務結束以後，資料庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預設規則，這包含資料的精確度、串聯性以及後續資料庫可以自發性地完成預定的工作。

比如A有500元，B有300元，A向B轉賬100，無論怎麼樣，A和B的總和總是800元

隔離性（Isolation）：資料庫允許多個併發事務同時對其資料進行讀寫和修改的能力，隔離性可以防止多個事務併發執行時由於交叉執行而導致資料的不一致。事務隔離分為不同級別，包括讀未提交（Read uncommitted）、讀提交（read committed）、可重複讀（repeatable read）和序列化（Serializable）。

永續性（Durability）：事務處理結束後，對資料的修改就是永久的，即便系統故障也不會丟失。

2. 2P/3P

2P= Two Phase commit   二段提交（RDBMS（關係型資料庫管理系統）經常就是這種機制，保證強一致性）

3P= Three Phase commit  三段提交

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

2.1 2P的兩個階段

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

階段2：執行事務提交（commit、rollback） 真正的提交事務

2.2 3P的三個階段

階段1：是否提交-詢問是否可以做事務提交

階段2：預先提交-預先提交事務

階段3：執行事務提交（commit、rollback）真正的提交事務

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

3. CAP理論

一致性（Consistency）：分散式資料庫的資料保持一致

可用性（Availability）：任何一個節點掛了，其他節點可以繼續對外提供服務

分割槽容錯性（網路分割槽）Partition tolerance：一個數據庫所在的機器壞了，如硬碟壞了，資料丟失了，可以新增一臺機器，然後從其他正常的機器把備份的資料同步過來

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

CA(放棄P)：將所有的資料放在一個節點。滿足一致性、可用性。

AP(放棄C)：放棄強一致性，用最終一致性來保證。

CP(放棄A)：一旦系統遇見故障，受到影響的伺服器需要等待一段時間，在恢復期間無法對外提供服務。

舉例說明CAP理論：

有3臺機器分別有3個數據庫分別有兩張表,資料都是一樣的

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插入數資料時，同時要把插入的資料同步到machine2、machine3，這就是一致性

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

3）當machine1的機器壞了，資料全部丟失了，不會有任何問題，因為machine2和machine3上還有資料，重新加一臺機器machine4，把machine2和machine3其中一臺機器的備份資料同步過來就可以了，這就是分割槽容錯性

4. BASE理論

基本可用（bascially available）、軟狀態（soft state）、最終一致性（Eventually consistent）

基本可用：在分散式系統出現故障，允許損失部分可用性（服務降級、頁面降級）

軟狀態：允許分散式系統出現中間狀態。而且中間狀態不影響系統的可用性。

1、這裡的中間狀態是指不同的data replication之間的資料更新可以出現延時的最終一致性

2、如CAP理論裡面的示例，當向machine1的db1的表tbl_person、tbl_order插入數資料時，同時要把插入的資料同步到machine2、machine3，當machine3的網路有問題時，同步失敗，但是過一會網路恢復了就同步成功了，這個同步失敗的狀態就稱為軟狀態，因為最終還是同步成功了。

最終一致性：data replications經過一段時間達到一致性。

5. Paxos演算法

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

拜占庭將軍問題

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

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

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

總結：

1）11位將軍進攻城池

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

3）不管撤退還是進攻，必須半數的將軍統一意見才可以執行

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

5.2 下面就來介紹一下Paxos演算法

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

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

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

Proposer：提交者（議案提交者）

          提交議案(判斷是否過半)，提交批准議案(判斷是否過半)

Acceptor：接收者（議案接收者）

          接受議案或者駁回議案，給proposer迴應(promise)

Learner：學習者（打醬油的）

         如果議案產生，學習議案。

設定1：如果Acceptor沒有接受議案，那麼他必須接受第一個議案

設定2：每個議案必須有一個編號，並且編號只能增長，不能重複。越往後越大。

設定3：接受編號大的議案，如果小於之前接受議案編號，那麼不接受

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

1）Prepare階段（議案提交）

a）Proposer希望議案V。首先發出Prepare請求至大多數Acceptor。Prepare請求內容為序列號K

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

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

d）否則，如果Acceptor之前接受過任何Prepare請求（如：MaxN），那麼比較議案編號，如果K<MaxN，則用reject或者error回覆Proposer

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

f）如果K>=MaxN，那麼檢查之前是否有批准的議案，如果有則回覆批准的議案編號和議案內容（如：<AcceptN, AcceptV>， AcceptN為批准的議案編號，AcceptV為批准的議案內容）

2）Accept階段（批准階段）

a）Proposer收到過半Acceptor發來的回覆，回覆都是OK，且沒有附帶任何批准過的議案編號和議案內容。那麼Proposer繼續提交批准請求，不過此時會連議案編號K和議案內容V一起提交（<K, V>這種資料形式）

b）Proposer收到過半Acceptor發來的回覆，回覆都是OK，且附帶批准過的議案編號和議案內容（<pok，議案編號，議案內容>）。那麼Proposer找到所有回覆中超過半數的那個（假設為<pok，AcceptNx，AcceptVx>）作為提交批准請求（請求為<K，AcceptVx>）傳送給Acceptor。

c）Proposer沒有收到過半Acceptor發來的回覆，則修改議案編號K為K+1，並將編號重新發送給Acceptors（重複Prepare階段的過程）

d）Acceptor收到Proposer發來的Accept請求，如果編號K<MaxN則不迴應或者reject。

e）Acceptor收到Proposer發來的Accept請求，如果編號K>=MaxN則批准該議案，並設定手裡批准的議案為<K，接受議案的編號，接受議案的內容>，回覆Proposer。

f）經過一段時間Proposer對比手裡收到的Accept回覆，如果超過半數，則結束流程（代表議案被批准），同時通知Leaner可以學習議案。

g) 經過一段時間Proposer對比手裡收到的Accept回覆，如果未超過半數，則修改議案編號重新進入Prepare階段。

5.3 Paxos示例

示例1：先後提議的場景

角色：

proposer：參謀1，參謀2

acceptor：將軍1，將軍2，將軍3（決策者）

1）參謀1發起提議，派通訊兵帶信給3個將軍，內容為（編號1）；

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

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

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

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

6）參謀2發起提議，派通訊兵帶信給3個將軍，內容為（編號2）；

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

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

示例2：交叉場景

角色：

proposer：參謀1，參謀2

acceptor：將軍1，將軍2，將軍3（決策者）

1）參謀1發起提議，派通訊兵帶信給3個將軍，內容為（編號1）；

相關推薦