到底什麼是集羣&分佈式

對於樓主這樣工做一年的菜鳥，偶爾會看到一些文章標題帶有「分佈式」「集羣」關鍵字，而後就懵逼了。最近對這些概念進行了必定的瞭解，整理了一下思路，在這裏分享給各位猿友。不足之處還望糾正，感謝。

事實上，在這一年的工做中，對一些分佈式和集羣技術也有一些接觸，只是研究得並不深刻。好比分佈式服務框架Dubbo、搜索引擎Elasticsearch。

概念老是抽象的，配合實例會讓你對概念的理解更加清晰。所以，若是恰好有使用到分佈式和集羣技術的猿友，能夠邊看本文的一些概念邊回想你使用過的分佈式和集羣技術。若是你沒有使用過相關技術，那其實也是能夠以瞭解的心態將本文看完，後面接觸到了，起碼會有個大概的印象。

下面咱們先看看其餘猿友對「分佈式」和「集羣」的見解：

（1）另一位博主的觀點（http://blog.csdn.net/bluishglc/article/details/5483162）

博主有對他的表述有做一點修改補充，方便各位猿友明天他的意思。

簡單說，分佈式是以縮短單個任務的執行時間來提高效率的，而集羣則是經過提升單位時間內執行的任務數來提高效率。

例如：

若是一個任務由10個子任務組成，每一個子任務單獨執行需1小時，則在一臺服務器上執行改任務需10小時。

採用分佈式方案，提供10臺服務器，每臺服務器只負責處理一個子任務，不考慮子任務間的依賴關係，執行完這個任務只需一個小時。(這種工做模式的一個典型表明就是Hadoop的Map/Reduce分佈式計算模型）

而採用集羣方案，一樣提供10臺服務器，每臺服務器都能獨立處理這個任務。假設有10個任務同時到達，10個服務器將同時工做，10小後，10個任務同時完成，這樣，整身來看，仍是平均1小時完成一個任務！（注意這裏的任務和子任務的區別）

（2）知乎（https://www.zhihu.com/question/20004877）

這個猿友描述得很簡單明瞭：

分佈式：一個業務分拆多個子業務，部署在不一樣的服務器上
集羣：同一個業務，部署在多個服務器上

另一位猿友從另一個角度去表述：

集羣是個物理形態，分佈式是個工做方式。

這位猿友的描述也很簡潔，可是比較抽象：

按照個人理解，集羣是解決高可用的，而分佈式是解決高性能、高併發的

（3）百度百科（http://baike.baidu.com/view/4804677.htm、http://baike.baidu.com/view/3022776.htm）

集羣：

集羣是一組相互獨立的、經過高速網絡互聯的計算機，它們構成了一個組，並以單一系統的模式加以管理。一個客戶與集羣相互做用時，集羣像是一個獨立的服務器。集羣配置是用於提升可用性和可縮放性。

分佈式：

一種基於網絡的計算機處理技術，與集中式相對應。因爲我的計算機的性能獲得極大的提升及其使用的普及，使處理能力分佈到網絡上的全部計算機成爲可能。分佈式計算是和集中式計算相對立的概念，分佈式計算的數據能夠分佈在很大區域。

看完這些是否是有種似懂非懂的感受？博主也是同樣！因此咱們接下來繼續瞭解。

上面博主有說過本身有接觸過度布式服務框架Dubbo，那麼咱們看看它爲何說本身是分佈式服務架構？（http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%83%8C%E6%99%AF）

分佈式服務架構
當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵。

偶然之間，有發現聽說「Git就是分佈式版本控制系統」，爲何它是分佈式的呢？（http://zhidao.baidu.com/link?url=WYNUjpVK8c-G5lq9EP6CMWAAwexIKduWUYlSC09iC5NRPYJI4L7HxoxgTRIiGxKoNQpBy4XCC_j_6toJOSbQzY8O6-NIXCBvUZ2–zcJwtK）

Git就是分佈式版本控制系統，對應的是集中式的版本控制如SVN。簡單的說，分佈式的版本控制就是每一個人均可以建立一個獨立的代碼倉庫用於管理，各類版本控制的操做均可以在本地完成。每一個人修改的代碼均可以推送合併到另一個代碼倉庫中。而像SVN這樣，只有一箇中央控制，全部的開發人員都必須依賴於這個代碼倉庫。每次版本控制的操做也必須連接到服務器才能完成。不少公司喜歡用集中式的版本控制是爲了更好的控制代碼。若是我的開發，就能夠選擇Git這種分佈式的。

從通常開發者的角度來看，git有如下功能：
1、從服務器上克隆完整的Git倉庫（包括代碼和版本信息）到單機上。
2、在本身的機器上根據不一樣的開發目的，建立分支，修改代碼。
3、在單機上本身建立的分支上提交代碼。
4、在單機上合併分支。
5、把服務器上最新版的代碼fetch下來，而後跟本身的主分支合併。
6、生成補丁（patch），把補丁發送給主開發者。
7、看主開發者的反饋，若是主開發者發現兩個通常開發者之間有衝突（他們之間能夠合做解決的衝突），就會要求他們先解決衝突，而後再由其中一我的提交。若是主開發者能夠本身解決，或者沒有衝突，就經過。
8、通常開發者之間解決衝突的方法，開發者之間可使用pull 命令解決衝突，解決完衝突以後再向主開發者提交補丁。

看了分佈式服務框架Dubbo和分佈式版本控制系統Git的這些描述後，細想一下，彷佛和上面的「分佈式：一個業務分拆多個子業務，部署在不一樣的服務器上，集羣：同一個業務，部署在多個服務器上」的觀點些類似。

Dubbo將核心業務抽取出來，做爲獨立的服務模塊，各個模塊之間只須要依賴接口，接口實現分離，那麼開發人員能夠各自完成本身負責的服務模塊，最後完成一個完整的系統。他們的目標是完成一個系統，而各個子服務模塊至關於子業務。Git也相似。

事實上，分佈式不少時候都開不了集羣的，在Dubbo、Hadoop、Elasticsearch都有體現。

如今分佈式概念可能咱們相對比較清晰了，集羣概念可能還比較模糊。另外，集羣是如何跟分佈式配合的呢，接下來咱們繼續瞭解集羣。

集羣主要分紅三大類( 高可用集羣， 負載均衡集羣，科學計算集羣)

高可用集羣( High Availability Cluster)

負載均衡集羣(Load Balance Cluster)

科學計算集羣(High Performance Computing Cluster)

1. 高可用集羣(High Availability Cluster)

常見的就是2個節點作成的HA集羣，有不少通俗的不科學的名稱，好比」雙機熱備」, 「雙機互備」, 「雙機」.
高可用集羣解決的是保障用戶的應用程序持續對外提供服務的能力。 (請注意高可用集羣既不是用來保護業務數據的，保護的是用戶的業務程序對外不間斷提供服務，把因軟件/硬件/人爲形成的故障對業務的影響下降到最小程度)。

2. 負載均衡集羣(Load Balance Cluster)

負載均衡系統：集羣中全部的節點都處於活動狀態，它們分攤系統的工做負載。通常Web服務器集羣、數據庫集羣和應用服務器集羣都屬於這種類型。

負載均衡集羣通常用於相應網絡請求的網頁服務器，數據庫服務器。這種集羣能夠在接到請求時，檢查接受請求較少，不繁忙的服務器，並把請求轉到這些服務器上。從檢查其餘服務器狀態這一點上看，負載均衡和容錯集羣很接近，不一樣之處是數量上更多。

3. 科學計算集羣(High Performance Computing Cluster)

高性能計算(High Perfermance Computing)集羣，簡稱HPC集羣。這類集羣致力於提供單個計算機所不能提供的強大的計算能力。

高性能計算分類：　
　
3.一、高吞吐計算(High-throughput Computing)
　
有一類高性能計算，能夠把它分紅若干能夠並行的子任務，並且各個子任務彼此間沒有什麼關聯。象在家搜尋外星人（ SETI@HOME – Search for Extraterrestrial Intelligence at Home ）就是這一類型應用。這一項目是利用Internet上的閒置的計算資源來搜尋外星人。SETI項目的服務器將一組數據和數據模式發給Internet上 參加SETI的計算節點，計算節點在給定的數據上用給定的模式進行搜索，而後將搜索的結果發給服務器。服務器負責將從各個計算節點返回的數據聚集成完整的 數據。由於這種類型應用的一個共同特徵是在海量數據上搜索某些模式，因此把這類計算稱爲高吞吐計算。所謂的Internet計算都屬於這一類。按照 Flynn的分類，高吞吐計算屬於SIMD（Single Instruction/Multiple Data）的範疇。
　　
3.二、分佈計算(Distributed Computing)

另外一類計算恰好和高吞吐計算相反，它們雖然能夠給分紅若干並行的子任務，可是子任務間聯繫很緊密，須要大量的數據交換。按照Flynn的分類，分佈式的高性能計算屬於MIMD（Multiple Instruction/Multiple Data）的範疇。

下面說說這幾種集羣的應用場景：

高可用集羣這裏很少做說明。

想Dubbo是比較偏向於負載均衡集羣，用過的猿友應該知道（不知道的能夠自行了解一下），Dubbo同一個服務是能夠有多個提供者的，當一個消費者過來，它要消費那個提供者，這裏是有負載均衡機制在裏面的。

搜索引擎Elasticsearch比較偏向於科學計算集羣的分佈計算。

而到這裏，可能很多猿友都知道，集羣的一些術語：集羣容錯、負載均衡。

咱們以Dubbo爲例：

集羣容錯（http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%94%99）

Dubbo提供了這些容錯策略：

集羣容錯模式：
能夠自行擴展集羣容錯策略，參見：集羣擴展

Failover Cluster
失敗自動切換，當出現失敗，重試其它服務器。(缺省)
一般用於讀操做，但重試會帶來更長延遲。
可經過retries="2"來設置重試次數(不含第一次)。

Failfast Cluster
快速失敗，只發起一次調用，失敗當即報錯。
一般用於非冪等性的寫操做，好比新增記錄。

Failsafe Cluster
失敗安全，出現異常時，直接忽略。
一般用於寫入審計日誌等操做。

Failback Cluster
失敗自動恢復，後臺記錄失敗請求，定時重發。
一般用於消息通知操做。

Forking Cluster
並行調用多個服務器，只要一個成功即返回。
一般用於實時性要求較高的讀操做，但須要浪費更多服務資源。
可經過forks="2"來設置最大並行數。

Broadcast Cluster
廣播調用全部提供者，逐個調用，任意一臺報錯則報錯。(2.1.0開始支持)
一般用於通知全部提供者更新緩存或日誌等本地資源信息。

負載均衡（http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1）

Dubbo提供了這些負載均衡策略：

Random LoadBalance
隨機，按權重設置隨機機率。
在一個截面上碰撞的機率高，但調用量越大分佈越均勻，並且按機率使用權重後也比較均勻，有利於動態調整提供者權重。

RoundRobin LoadBalance
輪循，按公約後的權重設置輪循比率。
存在慢的提供者累積請求問題，好比：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，長此以往，全部請求都卡在調到第二臺上。

LeastActive LoadBalance
最少活躍調用數，相同活躍數的隨機，活躍數指調用先後計數差。
使慢的提供者收到更少請求，由於越慢的提供者的調用先後計數差會越大。

ConsistentHash LoadBalance
一致性Hash，相同參數的請求老是發到同一提供者。
當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。
算法參見：http://en.wikipedia.org/wiki/Consistent_hashing。
缺省只對第一個參數Hash，若是要修改，請配置<dubbo:parameter key="hash.arguments" value="0,1" />
缺省用160份虛擬節點，若是要修改，請配置<dubbo:parameter key="hash.nodes" value="320" />

還有比較好奇它們是怎麼通訊的？

像早期版本的Elasticsearch的話，自動發現節點機制，ES是一個基於p2p的系統，它先經過廣播尋找存在的節點，再經過多播協議來進行節點之間的通訊，同時也支持點對點的交互。

而Dubbo是有個註冊中心，它支持多個註冊中心，可是推薦使用ZooKeeper。關於ZooKeeper能夠自行了解，不少集羣相關的框架都有使用到它。固然像Elasticsearch是本身有相應的機制實現的。

就到這裏吧，小寶鴿也是有點累了，準備先下班了~~~~~~~~