分佈式系統簡介

什麼是分佈式系統

分佈式系統（distributed  system）具備高度的 內聚性 和 透明性。

    內聚性：每個節點高度自治，有本地的數據庫管理系統；

    透明性：每個數據庫分佈節點對用戶來講是透明的，用戶是感受不到"分佈"的，即用戶不須要知道關係是否分割、有無副本、數據位於哪一個節點、事物在哪一個站點上執行等；

CAP原理

• c：一致性（Consistency）

在分佈式系統中的全部數據備份，在同一時刻是否一樣的值；

• a：可用性（Availability）

在集羣中一部分節點故障後，集羣總體是否還能響應客戶端的讀寫請求；

• p： 分區 容忍性（Partition Rolerance）

分區至關與對通訊的時限要求，消息體若是不能在時限內達成數據一致性，意味着發生了分區的狀況。

所以分區容忍性是基本要求，不然就失去了價值。所以分佈式數據系統，就是在一致性和可用性之間取一個平衡。對於大多數的web應用，並不須要強一致性，一般作法是以強一致性爲代價換取高可用，這也是多數分佈式數據庫產品的方向。

這裏的犧牲一致性，指的是再也不要求關係型數據庫中的強一致性，只要能達到最終一致性便可，這個時間窗口對用戶來講是透明的，用戶是感知不到的。一般的作法，是通過多份異步複製來實現系統的高可用和數據的最終一致性，時間窗口取決於數據複製到一致狀態的時間。

關於最終一致性

    一致性問題是由於出現了併發的讀操做或者寫操做。對於客戶端，多進程併發訪問時，更新過的數據在不一樣進程中如何獲取的不一樣策略，決定了不一樣的一致性。

    強一致性：對於關係型數據庫，要求更新過的數據能被後續的訪問都能看到；

    弱一致性：若是容忍後續的部分或者所有訪問不到，這就是弱一致性；

    最終一致性：若是通過一段時間以後，要求可以訪問到更新後的數據，就是最終一致性；

從數據的同步看強弱一致性

    對於服務器而言，如何儘快將更新後的數據分佈到整個系統，下降最終一致性的時間窗口，對分佈式系統來講是十分重要的。

    咱們假設，如今有一個分佈式系統，數據保存了 N 份，更新數據須要保證寫完成的節點數爲 W ，讀取數據時須要讀取的節點數爲 R ：

    若是 W＋R > N, 說明讀寫節點重複，則是強一致性，如一主一備同步複製的關係型數據庫；

    若是 W＋R <= N, 則是弱一致性，好比一主一備異步複製的數據庫，讀取備庫，可能沒法讀取主庫已經更新過的數據。

    對於分佈式數據庫而言，爲了保證高可用，通常設置 N >= 3。

分佈式系統架構思路

兩種思路

    1. 如今有一臺服務器，一臺服務器能夠處理 100w/s 的請求，隨着業務增加，據估算，訪問量最高會達到 200w/s ，若是不進行處理，服務器會拒絕訪問，甚至會 出現宕機。最簡單的方案，就是再增長一臺機器（在實際環境中，增長機器來解決問題是經常使用的一種解決方案），每臺機器承擔一半的請求，若是訪問量繼續增長的話，能夠繼續經過增長機器來解決問題。這就是水平擴展。這裏暫時不討論如何進行負載的均衡；

    2. 如今有一個應用對外提供項服務，每項服務都是一個請求，當前服務器能夠承擔 100w/s 的請求，目前統計， A 服務 40w/s ， B 服務 40w/s。業務一樣擴大，服務 A 和服務 B 的請求都增長了一倍，有須要進行擴展。使用兩臺機器進行平分，每臺機器承擔服務 A 和服務 B 各一半，平分的話太複雜，不如一臺機器只負責服務 A， 亮一臺機器只負責業務 B，這種方式叫作垂直擴展。

    簡單對水擴展和垂直擴展進行總結，能夠發現，按照業務進行拆分，便是垂直擴展；按請求進行拆分，即水平擴展。

負載均衡

負載均衡要作的任務，就是肯定客戶端的請求，應該發往分佈式系統中的哪一臺服務器上，一般的作法，就是經過一臺中間服務器，來實現請求的分配。

常見的負載均衡策略：

1. FastDFS 分佈式系統：client 向 tracker 詢問一臺能夠進行文件下載的 storage ，tracker 返回一臺可用的 storage，client 直接和 storage 進行通訊完成文件下載；

這裏的 tracker 就是負載均衡服務器；

2. 分佈式RPC中間件 Hedwig：client 向 zookeeper詢問哪臺服務器能夠執行請求；zookeeper 返回一臺可用的 server；client 直接和 service 完成通訊。

zookeeper 是分佈式系統中一個負載均衡框架，Google 的 chubby 的一個開源實現，是 Hadoop 和 Hbase 的重要組件

3. nginx也是一個負載均衡服務器，面向的是分佈式web服務器

負載均衡調度算法

1. 輪詢

    使用這種方式，全部標記進入虛擬服務的服務器應該有相近的資源容量以及負載形同的應用程序。

2. 加權輪循(Weighted Round Robin)

    解決了輪詢的缺點，提早爲每臺服務器根據資源及能力大小分配權重，傳入的請求按順序，根據權重，順序分配給集羣中的服務器。

3. 最少鏈接數

    上面兩種方式，都不可以肯定系統不能識別在給定的時間裏保持了多少鏈接。因爲不一樣鏈接處理的時間不一樣，可能發生服務器 A 上處理的鏈接少於 B，可是A已經超載，由於A上用戶打開鏈接持續的時間更長。

    這種潛在的問題，能夠經過「最少鏈接數」算法來避免，客戶端的請求是根據每臺機器當前打開的鏈接數來分配的，即活躍鏈接數最少的服務器會自動接收下一個傳入的請求。

與簡單輪詢同樣，每臺服務器也須要有相近的資源容量以及負載形同的應用程序；須要注意的是，在流量率低的配置環境中，個服務器的流量並不相同，會有限考慮第一臺服務器。

4. 加權最少鏈接

    若是服務器資源容量各不相同，那麼「加權最少鏈接」更爲合適。這種分配方式結合了鏈接和權重二者的優點，大多數狀況下，這是一種至關公平的算法。

一樣，這種方式須要和最少鏈接數注意相同的問題。

5. 最少鏈接數慢啓動時間

    對於方式 3 和方式 4 來講，當集羣中新增一個節點後，能夠爲其配置一個時間段，這個段時間內鏈接數是有限制的，並且是緩慢增長的，這爲服務器提供了一個「過分時間」。

6. 源 IP 哈希

    經過生成源 IP 的哈希值，並經過這個哈希值來找到正確的真實服務器，意味着對於同一主機的請求，對應的服務器老是相同的，可是這種方式會致使服務器負載不均衡。