什麽是分布式系統

分布式系統（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 的哈希值，並通過這個哈希值來找到正確的真實服務器，意味著對於同一主機的請求，對應的服務器總是相同的，但是這種方式會導致服務器負載不均衡。

本文出自 “暮回” 博客，請務必保留此出處http://muhuizz.blog.51cto.com/11321490/1965930

分布式系統簡介