分散式架構的基本理論及應用

分散式一致性
對於不同業務的產品，我們對資料一致性的要求 是不一樣的，比如12306要求的是資料的嚴格一致性，而銀行轉賬要求的是資料的最終一致性，所以，使用者在使用不同的產品的時候對數 據一致性的要求是不一樣的 。
在分散式系統中要解決的一個重要問題就是資料的複製，因為資料庫複製期間存在延時。
所謂的分散式一致性問題，是指在分散式環境中引入資料 複製機制之後，不同資料節點之間 可能出現的，並無法依 靠計算機應用程式自身解決的資料不一致的情況。簡單講， 資料一致性就是指在對一個副本資料進行更新的時候，必 須確保也能夠更新其他的 副本，否則不同副本之間的資料 將不一致。如果是因為網路延遲導致的問題，可以把同 步動作進行阻塞，使用者在查詢的時候必須要等到資料同 步完成以後再來做。但是這個方案帶來的問題是效能會受到非常大的影響。如果同步的資料比較多或者比較頻繁，那麼因為阻塞操作可能將導致整個新系統不可用的情況。
所以沒有辦法找到一種能夠滿足資料一致性、 又不影響系統執行的效能的方案，因此這裡就產生了一個一致性的級別：

1. 強一致性：這種一致性級別是最符合使用者直覺的，它要 求系統寫入什麼，讀出來的也會是什麼，使用者體驗好，但 實現起來往往對系統的效能影響大
2. 弱一致性：這種一致性級別約束了系統在寫入成功後， 不承諾立即可以讀到寫入的值，也不久承諾多久之後資料 能夠達到一致，但會盡可能地保證到某個時間級別（比如 秒級別）後，資料能夠達到一致狀態
3. 最終一致性：最終一致性是弱一致性的一個特例，系統 會保證在一定時間內，能夠達到一個數據一致的狀態。這 裡之所以將最終一致性單獨提出來，是因為它是弱一致性 中非常推崇的一種一致性模型，也是業界在大型分散式系 統的資料一致性上比較用的多的模型。
   CAP 理論
   
   是一個經典的分散式系統理論。它告訴我們：一個分 布式系統不可能同時滿足一致性（C：Consistency）、可用 性（ A：Availability）和分割槽容錯性（P：Partition tolerance） 這三個基本需求，最多隻能同時滿足其中兩項。CAP理論在網際網路界有著廣泛的知名度，也被稱為“帽子理論”。
   一致性：所有節點上的資料時刻保持同步。
   可用性：每個請求都能接收一個響應，無論響應成功或失 敗。
   分割槽容錯：系統應該持續提供服務，即使系統內部（某個 節點分割槽）有訊息丟失。比如交換機失敗、網址網路被分 成幾個子網，形成腦裂；伺服器發生網路延遲或宕機，導 致某些server與叢集中的其他機器失去聯絡 等。

分割槽是導致分散式系統可靠性問題的固有特性，從本質上 來看，CAP理論的準確描述不應該是從3個特性中選取兩 個，所以我們只能被迫適應，根本沒有選擇權； CAP並不是一個普適性原理和指導思想，它僅 適用於原子讀寫的NoSql場景中，並不適用於資料庫系統。

BASE 理論
從前面的分析中知道：在分散式（資料庫分片或分庫存在 的多個例項上）系統下，CAP理論並不適合資料庫事務（因 為更新一些錯誤的資料而導致的失敗，無論使用什麼樣的 高可用方案都是徒勞，因為資料發生了無法修正的錯誤）。 此外 XA 事務雖然保證了資料庫在分散式系統下的 ACID （原子性、一致性、隔離性、永續性）特性，但也帶來了一 些效能方面的代價，對於併發和響應時間要求比較高的電 商平臺來說，是很難接受的。
BASE 全稱 是Basically available,soft-state,Eventually Consistent. 指的是系統基本可用、軟狀態、資料最終一致性。相對於CAP來 說，它大大降低了我們對系統的要求。
Basically available（基本可用），在分散式系統出現不可預 知的故障時，允許瞬時部分可用性 ，如在淘寶上搜索商品的時間由1秒變成3秒；再比如資料庫採用分片模式，100W 個使用者資料分在 5 個數據庫例項上，如果破壞了一個例項，那麼可用性是有80%的使用者都可以登入，系統仍然可用； 電商大促時，為了應對訪問量激增，部分使用者可能會被 引導到降級頁面，服務層也可能只提供降級服務。這就 是損失部分可用性的體現。
soft-state（軟狀態）. 表示系統中的資料存在中間狀態，並 且這個中間狀態的存在不會影響系統的整體可用性，即系統允許在不同節點的資料副本之間進行資料同步 過程中存在延時； 比如訂單狀態的待支付、支付中、 支付成功、支付失敗，支付中就是一箇中間狀態，這 箇中間狀態在支付成功以後，在支付表中的狀態同步給訂 單狀態之前，中間會存在一個時間內的不一致。
Eventually consistent（資料的最終一致性），表示的是所有 資料副本在一段時間的同步後最終都能達到一個一直的狀 態，因此最終一致性的本質是要保證資料最終達到一致， 而不需要實時保證系統資料的強一致 。
BASE理論的核心思想是：即使無法做到強一致性，但每個 應用都可以根據自身業務特點，採用適當的方式來使系統 達到最終一致性 。

分散式架構下的高可用設計

1. 避免單點故障
   a) 負載均衡技術（failover/選址/硬體負載/ 軟體負載/去中心化的軟體負載（gossip(rediscluster)））
   b) 熱備（linux HA）
   c) 多機房（同城災備、異地災備）
2. 應用的高可用性
   a) 故障監控（系統監控（cpu、記憶體） /鏈路監控/日誌監 控） 自動預警
   b) 應用的容錯設計、 （服務降級、限流）自我保護能力
   c) 資料量（資料分片、讀寫分離）
   分散式架構下的可伸縮設計
   垂直伸縮 ：提升硬體能力
   水平伸縮 ：增加伺服器
   3.加速靜態內容訪問速度的 CDN
   CDN是Content Delivery Network的縮寫，表示的是內容 分發網路。CDN的作用是把使用者需要的內容分發到離使用者 最近的地方，這樣可以使使用者能夠快速獲取所需要的內容。
   CDN其實就是一種網路快取技術，能夠把一些相對穩定的 資源放到距離終端使用者較近的地方，一方面可以節省整個廣域網的頻寬消耗，另外一方面可以提升使用者的訪問速度， 改進使用者體驗。我們一般會把靜態的檔案（圖片、指令碼、靜 態頁面）放到CDN中，如圖所示：
   
3. 當用戶點選網站頁面上的內容URL，經過本地DNS系統解析，DNS系統會最終將域名的解析權交給 CNAME 指向的 CDN 專用 DNS 伺服器
4. CDN的DNS伺服器將CDN的全域性負載均衡裝置IP地址返回使用者
5. 使用者向CDN的全域性負載均衡裝置發起內容URL訪問請求
6. CDN全域性負載均衡裝置根據使用者IP地址，以及使用者請求的內容URL，選擇一臺使用者所屬區域的區域負載均衡裝置，告訴使用者向這臺裝置發起請求。
7. 區域負載均衡裝置會為使用者選擇一臺合適的快取伺服器提供服務，選擇的依據包括：根據使用者IP地址，判斷哪一臺伺服器距使用者最近；根據使用者所請求的 URL 中攜帶的內容名稱，判斷哪一臺伺服器上有使用者所需內容；查詢各個伺服器當前的負載情況，判斷哪一臺伺服器
   尚有服務能力。基於以上這些條件的綜合分析之後，區域負載均衡裝置會向全域性負載均衡裝置返回一臺快取伺服器的IP地址
8. 全域性負載均衡裝置把伺服器的IP地址返回給使用者 使用者向快取伺服器發起請求，快取伺服器響應使用者請求，將使用者所需內容傳送到使用者終端。如果這臺快取伺服器上並沒有使用者想要的內容，而區域均衡裝置依然將它分配給了使用者，那麼這臺伺服器就要向它的上一級快取伺服器請求內容，直至追溯到網站的源伺服器將內容拉到本地。

什麼情況下用 CDN
最適合的是那些不會經常變化的內容，比如圖片， JS檔案， CSS 檔案，圖片檔案包括程式模板中的，CSS 檔案中用到 的背景圖片，還有就是作為網站內容組成部分的那些圖片， 都可以；
灰度釋出
我們的應用雖然經過了測試部門的測試，但是仍然很難全 面覆蓋使用者的使用場景，為了保證萬無一失，我們在進行釋出的時候一般會採用灰度釋出，也就是會對新應用進行 分批發布，逐步擴大新應用在整個叢集中的比例直到最後 全部完成。灰度釋出是針對新引用在使用者體驗方面完全無 感知。 灰度釋出系統的作用是可以根據自己的配置，來將用 戶的流量導到新上線的系統上，來快速驗證新的功能修改， 而一旦出問題，也可以馬上的恢復，簡單的說，就是一套 A/BTest系統．

上一篇：構建分散式架構的重要因素
下一篇：領域驅動設計