來(lái)自：小寶鴿 - CSDN博客 http://blog.csdn.net/u013142781

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

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

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

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

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

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

博主有對(duì)他的表述有作一點(diǎn)修改補(bǔ)充，方便各位猿友明了他的意思。

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

例如：

如果一個(gè)任務(wù)由10個(gè)子任務(wù)組成，每個(gè)子任務(wù)單獨(dú)執(zhí)行需1小時(shí)，則在一臺(tái)服務(wù)器上執(zhí)行改任務(wù)需10小時(shí)。

采用分布式方案，提供10臺(tái)服務(wù)器，每臺(tái)服務(wù)器只負(fù)責(zé)處理一個(gè)子任務(wù)，不考慮子任務(wù)間的依賴(lài)關(guān)系，執(zhí)行完這個(gè)任務(wù)只需一個(gè)小時(shí)。(這種工作模式的一個(gè)典型代表就是Hadoop的Map/Reduce分布式計(jì)算模型）

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

（2）

這個(gè)猿友描述得很簡(jiǎn)單明了：

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

另外一位猿友從另外一個(gè)角度去表述：

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

這位猿友的描述也很簡(jiǎn)潔，但是比較抽象：

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

（3）

集群：

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

分布式：

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

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

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

分布式服務(wù)架構(gòu)

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

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

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

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

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

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

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

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

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

集群主要分成三大類(lèi) （高可用集群， 負(fù)載均衡集群，科學(xué)計(jì)算集群）

高可用集群( High Availability Cluster)
負(fù)載均衡集群(Load Balance Cluster)
科學(xué)計(jì)算集群(High Performance Computing Cluster)

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

常見(jiàn)的就是2個(gè)節(jié)點(diǎn)做成的HA集群，有很多通俗的不科學(xué)的名稱(chēng)，比如”雙機(jī)熱備”, “雙機(jī)互備”, “雙機(jī)”。

高可用集群解決的是保障用戶(hù)的應(yīng)用程序持續(xù)對(duì)外提供服務(wù)的能力。 (請(qǐng)注意高可用集群既不是用來(lái)保護(hù)業(yè)務(wù)數(shù)據(jù)的，保護(hù)的是用戶(hù)的業(yè)務(wù)程序?qū)ν獠婚g斷提供服務(wù)，把因軟件/硬件/人為造成的故障對(duì)業(yè)務(wù)的影響降低到最小程度)。

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

負(fù)載均衡系統(tǒng)：集群中所有的節(jié)點(diǎn)都處于活動(dòng)狀態(tài)，它們分?jǐn)傁到y(tǒng)的工作負(fù)載。一般Web服務(wù)器集群、數(shù)據(jù)庫(kù)集群和應(yīng)用服務(wù)器集群都屬于這種類(lèi)型。

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

3、科學(xué)計(jì)算集群(High Performance Computing Cluster)

高性能計(jì)算(High Perfermance Computing)集群，簡(jiǎn)稱(chēng)HPC集群。這類(lèi)集群致力于提供單個(gè)計(jì)算機(jī)所不能提供的強(qiáng)大的計(jì)算能力。

高性能計(jì)算分類(lèi)：　

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

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

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

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

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

下面說(shuō)說(shuō)這幾種集群的應(yīng)用場(chǎng)景：

高可用集群這里不多作說(shuō)明。

想Dubbo是比較偏向于負(fù)載均衡集群，用過(guò)的猿友應(yīng)該知道（不知道的可以自行了解一下），Dubbo同一個(gè)服務(wù)是可以有多個(gè)提供者的，當(dāng)一個(gè)消費(fèi)者過(guò)來(lái)，它要消費(fèi)那個(gè)提供者，這里是有負(fù)載均衡機(jī)制在里面的。

搜索引擎Elasticsearch比較偏向于科學(xué)計(jì)算集群的分布計(jì)算。

而到這里，可能不少猿友都知道，集群的一些術(shù)語(yǔ)：集群容錯(cuò)、負(fù)載均衡。

我們以Dubbo為例：

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

Dubbo提供了這些容錯(cuò)策略：

集群容錯(cuò)模式：
可以自行擴(kuò)展集群容錯(cuò)策略，參見(jiàn)：集群擴(kuò)展

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

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

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

Failback Cluster
失敗自動(dòng)恢復(fù)，后臺(tái)記錄失敗請(qǐng)求，定時(shí)重發(fā)。
通常用于消息通知操作。

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

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

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

Dubbo提供了這些負(fù)載均衡策略：

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

RoundRobin LoadBalance
輪循，按公約后的權(quán)重設(shè)置輪循比率。
存在慢的提供者累積請(qǐng)求問(wèn)題，比如：第二臺(tái)機(jī)器很慢，但沒(méi)掛，當(dāng)請(qǐng)求調(diào)到第二臺(tái)時(shí)就卡在那，久而久之，所有請(qǐng)求都卡在調(diào)到第二臺(tái)上。

LeastActive LoadBalance
最少活躍調(diào)用數(shù)，相同活躍數(shù)的隨機(jī)，活躍數(shù)指調(diào)用前后計(jì)數(shù)差。
使慢的提供者收到更少請(qǐng)求，因?yàn)樵铰奶峁┱叩恼{(diào)用前后計(jì)數(shù)差會(huì)越大。

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

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

像早期版本的Elasticsearch的話(huà)，自動(dòng)發(fā)現(xiàn)節(jié)點(diǎn)機(jī)制，ES是一個(gè)基于p2p的系統(tǒng)，它先通過(guò)廣播尋找存在的節(jié)點(diǎn)，再通過(guò)多播協(xié)議來(lái)進(jìn)行節(jié)點(diǎn)之間的通信，同時(shí)也支持點(diǎn)對(duì)點(diǎn)的交互。

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

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

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