來自：小寶鴿 - CSDN博客 http://blog.csdn.net/u013142781

鏈接：http://blog.csdn.net/u013142781/article/details/51307229（點擊尾部閱讀原文前往）

對于樓主這樣工作一年的菜鳥，偶爾會看到一些文章標題帶有“分布式”“集群”關鍵字，然后就懵逼了。最近對這些概念進行了一定的了解，整理了一下思路，在這里分享給各位猿友。不足之處還望糾正，感謝。

事實上，在這一年的工作中，對一些分布式和集群技術也有一些接觸，只是研究得并不深入。比如分布式服務框架Dubbo、搜索引擎Elasticsearch。

概念總是抽象的，配合實例會讓你對概念的理解更加清晰。因此，如果剛好有使用到分布式和集群技術的猿友，可以邊看本文的一些概念邊回想你使用過的分布式和集群技術。如果你沒有使用過相關技術，那其實也是可以以了解的心態(tài)將本文看完，后面接觸到了，起碼會有個大概的印象。

下面我們先看看其他猿友對“分布式”和“集群”的看法：

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

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

簡單說，分布式是以縮短單個任務的執(zhí)行時間來提升效率的，而集群則是通過提高單位時間內(nèi)執(zhí)行的任務數(shù)來提升效率。

例如：

如果一個任務由10個子任務組成，每個子任務單獨執(zhí)行需1小時，則在一臺服務器上執(zhí)行改任務需10小時。

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

而采用集群方案，同樣提供10臺服務器，每臺服務器都能獨立處理這個任務。假設有10個任務同時到達，10個服務器將同時工作，10小后，10個任務同時完成，這樣，整身來看，還是平均1小時完成一個任務?。ㄗ⒁膺@里的任務和子任務的區(qū)別）

（2）

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

分布式：一個業(yè)務分拆多個子業(yè)務，部署在不同的服務器上
集群：同一個業(yè)務，部署在多個服務器上

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

集群是個物理形態(tài)，分布式是個工作方式。

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

按照我的理解，集群是解決高可用的，而分布式是解決高性能、高并發(fā)的

（3）

集群：

集群是一組相互獨立的、通過高速網(wǎng)絡互聯(lián)的計算機，它們構成了一個組，并以單一系統(tǒng)的模式加以管理。一個客戶與集群相互作用時，集群像是一個獨立的服務器。集群配置是用于提高可用性和可縮放性。

分布式：

一種基于網(wǎng)絡的計算機處理技術，與集中式相對應。由于個人計算機的性能得到極大的提高及其使用的普及，使處理能力分布到網(wǎng)絡上的所有計算機成為可能。分布式計算是和集中式計算相對立的概念，分布式計算的數(shù)據(jù)可以分布在很大區(qū)域。

看完這些是不是有種似懂非懂的感覺？博主也是一樣！所以我們接下來繼續(xù)了解。

上面博主有說過自己有接觸過分布式服務框架Dubbo，那么我們看看它為什么說自己是分布式服務架構？（http:///User Guide-zh.htm#UserGuide-zh-%E8%83%8C%E6%99%AF）

分布式服務架構

當垂直應用越來越多，應用之間交互不可避免，將核心業(yè)務抽取出來，作為獨立的服務，逐漸形成穩(wěn)定的服務中心，使前端應用能更快速的響應多變的市場需求。
此時，用于提高業(yè)務復用及整合的 分布式服務框架(RPC) 是關鍵。

偶然之間，有發(fā)現(xiàn)據(jù)說“Git就是分布式版本控制系統(tǒng)”，為什么它是分布式的呢？（http://zhidao.baidu.com/link?url=WYNUjpVK8c-G5lq9EP6CMWAAwexIKduWUYlSC09iC5NRPYJI4L7HxoxgTRIiGxKoNQpBy4XCC_j_6toJOSbQzY8O6-NIXCBvUZ2–zcJwtK）

Git就是分布式版本控制系統(tǒng)，對應的是集中式的版本控制如SVN。簡單的說，分布式的版本控制就是每個人都可以創(chuàng)建一個獨立的代碼倉庫用于管理，各種版本控制的操作都可以在本地完成。每個人修改的代碼都可以推送合并到另外一個代碼倉庫中。而像SVN這樣，只有一個中央控制，所有的開發(fā)人員都必須依賴于這個代碼倉庫。每次版本控制的操作也必須鏈接到服務器才能完成。很多公司喜歡用集中式的版本控制是為了更好的控制代碼。如果個人開發(fā)，就可以選擇Git這種分布式的。

從一般開發(fā)者的角度來看，git有以下功能：

1、從服務器上克隆完整的Git倉庫（包括代碼和版本信息）到單機上。
2、在自己的機器上根據(jù)不同的開發(fā)目的，創(chuàng)建分支，修改代碼。
3、在單機上自己創(chuàng)建的分支上提交代碼。
4、在單機上合并分支。
5、把服務器上最新版的代碼fetch下來，然后跟自己的主分支合并。
6、生成補?。╬atch），把補丁發(fā)送給主開發(fā)者。
7、看主開發(fā)者的反饋，如果主開發(fā)者發(fā)現(xiàn)兩個一般開發(fā)者之間有沖突（他們之間可以合作解決的沖突），就會要求他們先解決沖突，然后再由其中一個人提交。如果主開發(fā)者可以自己解決，或者沒有沖突，就通過。
8、一般開發(fā)者之間解決沖突的方法，開發(fā)者之間可以使用pull 命令解決沖突，解決完沖突之后再向主開發(fā)者提交補丁。

看了分布式服務框架Dubbo和分布式版本控制系統(tǒng)Git的這些描述后，細想一下，似乎和上面的“分布式：一個業(yè)務分拆多個子業(yè)務，部署在不同的服務器上，集群：同一個業(yè)務，部署在多個服務器上”的觀點些相似。

Dubbo將核心業(yè)務抽取出來，作為獨立的服務模塊，各個模塊之間只需要依賴接口，接口實現(xiàn)分離，那么開發(fā)人員可以各自完成自己負責的服務模塊，最后完成一個完整的系統(tǒng)。他們的目標是完成一個系統(tǒng)，而各個子服務模塊相當于子業(yè)務。Git也類似。

事實上，分布式很多時候都開不了集群的，在Dubbo、Hadoop、Elasticsearch都有體現(xiàn)。

現(xiàn)在分布式概念可能我們相對比較清晰了，集群概念可能還比較模糊。另外，集群是如何跟分布式配合的呢，接下來我們繼續(xù)了解集群。

集群主要分成三大類 （高可用集群， 負載均衡集群，科學計算集群）

高可用集群( High Availability Cluster)
負載均衡集群(Load Balance Cluster)
科學計算集群(High Performance Computing Cluster)

1、高可用集群(High Availability Cluster)

常見的就是2個節(jié)點做成的HA集群，有很多通俗的不科學的名稱，比如”雙機熱備”, “雙機互備”, “雙機”。

高可用集群解決的是保障用戶的應用程序持續(xù)對外提供服務的能力。 (請注意高可用集群既不是用來保護業(yè)務數(shù)據(jù)的，保護的是用戶的業(yè)務程序對外不間斷提供服務，把因軟件/硬件/人為造成的故障對業(yè)務的影響降低到最小程度)。

2、負載均衡集群(Load Balance Cluster)

負載均衡系統(tǒng)：集群中所有的節(jié)點都處于活動狀態(tài)，它們分攤系統(tǒng)的工作負載。一般Web服務器集群、數(shù)據(jù)庫集群和應用服務器集群都屬于這種類型。

負載均衡集群一般用于相應網(wǎng)絡請求的網(wǎng)頁服務器，數(shù)據(jù)庫服務器。這種集群可以在接到請求時，檢查接受請求較少，不繁忙的服務器，并把請求轉到這些服務器上。從檢查其他服務器狀態(tài)這一點上看，負載均衡和容錯集群很接近，不同之處是數(shù)量上更多。

3、科學計算集群(High Performance Computing Cluster)

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

高性能計算分類：　

3.1、高吞吐計算(High-throughput Computing)

有一類高性能計算，可以把它分成若干可以并行的子任務，而且各個子任務彼此間沒有什么關聯(lián)。象在家搜尋外星人（ SETI@HOME – Search for Extraterrestrial Intelligence at Home ）就是這一類型應用。

這一項目是利用Internet上的閑置的計算資源來搜尋外星人。SETI項目的服務器將一組數(shù)據(jù)和數(shù)據(jù)模式發(fā)給Internet上參加SETI的計算節(jié)點，計算節(jié)點在給定的數(shù)據(jù)上用給定的模式進行搜索，然后將搜索的結果發(fā)給服務器。服務器負責將從各個計算節(jié)點返回的數(shù)據(jù)匯集成完整的 數(shù)據(jù)。因為這種類型應用的一個共同特征是在海量數(shù)據(jù)上搜索某些模式，所以把這類計算稱為高吞吐計算。

所謂的Internet計算都屬于這一類。按照 Flynn的分類，高吞吐計算屬于SIMD（Single Instruction/Multiple Data）的范疇。
　　
3.2、分布計算(Distributed Computing)

另一類計算剛好和高吞吐計算相反，它們雖然可以給分成若干并行的子任務，但是子任務間聯(lián)系很緊密，需要大量的數(shù)據(jù)交換。按照Flynn的分類，分布式的高性能計算屬于MIMD（Multiple Instruction/Multiple Data）的范疇。

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

高可用集群這里不多作說明。

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

搜索引擎Elasticsearch比較偏向于科學計算集群的分布計算。

而到這里，可能不少猿友都知道，集群的一些術語：集群容錯、負載均衡。

我們以Dubbo為例：

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

Dubbo提供了這些容錯策略：

集群容錯模式：
可以自行擴展集群容錯策略，參見：集群擴展

Failover Cluster
失敗自動切換，當出現(xiàn)失敗，重試其它服務器。(缺省)
通常用于讀操作，但重試會帶來更長延遲。
可通過retries='2'來設置重試次數(shù)(不含第一次)。

Failfast Cluster
快速失敗，只發(fā)起一次調(diào)用，失敗立即報錯。
通常用于非冪等性的寫操作，比如新增記錄。

Failsafe Cluster
失敗安全，出現(xiàn)異常時，直接忽略。
通常用于寫入審計日志等操作。

Failback Cluster
失敗自動恢復，后臺記錄失敗請求，定時重發(fā)。
通常用于消息通知操作。

Forking Cluster
并行調(diào)用多個服務器，只要一個成功即返回。
通常用于實時性要求較高的讀操作，但需要浪費更多服務資源。
可通過forks='2'來設置最大并行數(shù)。

Broadcast Cluster
廣播調(diào)用所有提供者，逐個調(diào)用，任意一臺報錯則報錯。(2.1.0開始支持)
通常用于通知所有提供者更新緩存或日志等本地資源信息。

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

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

Random LoadBalance
隨機，按權重設置隨機概率。
在一個截面上碰撞的概率高，但調(diào)用量越大分布越均勻，而且按概率使用權重后也比較均勻，有利于動態(tài)調(diào)整提供者權重。

RoundRobin LoadBalance
輪循，按公約后的權重設置輪循比率。
存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調(diào)到第二臺時就卡在那，久而久之，所有請求都卡在調(diào)到第二臺上。

LeastActive LoadBalance
最少活躍調(diào)用數(shù)，相同活躍數(shù)的隨機，活躍數(shù)指調(diào)用前后計數(shù)差。
使慢的提供者收到更少請求，因為越慢的提供者的調(diào)用前后計數(shù)差會越大。

ConsistentHash LoadBalance
一致性Hash，相同參數(shù)的請求總是發(fā)到同一提供者。
當某一臺提供者掛時，原本發(fā)往該提供者的請求，基于虛擬節(jié)點，平攤到其它提供者，不會引起劇烈變動。
算法參見：http://en./wiki/Consistent_hashing。
缺省只對第一個參數(shù)Hash，如果要修改，請配置<dubbo:parameter key='hash.arguments' value='0,1' />
缺省用160份虛擬節(jié)點，如果要修改，請配置<dubbo:parameter key='hash.nodes' value='320' />

還有比較好奇它們是怎么通信的？

像早期版本的Elasticsearch的話，自動發(fā)現(xiàn)節(jié)點機制，ES是一個基于p2p的系統(tǒng)，它先通過廣播尋找存在的節(jié)點，再通過多播協(xié)議來進行節(jié)點之間的通信，同時也支持點對點的交互。

而Dubbo是有個注冊中心，它支持多個注冊中心，但是推薦使用ZooKeeper。關于ZooKeeper可以自行了解，很多集群相關的框架都有使用到它。當然像Elasticsearch是自己有相應的機制實現(xiàn)的。

●本文編號165，以后想閱讀這篇文章直接輸入165即可。

●輸入m可以獲取到文章目錄