對於樓主這樣工作一年的菜鳥，偶爾會看到一些文章標題帶有“分佈式”“集羣”關鍵字，然後就懵逼了。最近對這些概念進行了一定的瞭解，整理了一下思路，在這裏分享給各位猿友。不足之處還望糾正，感謝。
事實上，在這一年的工作中，對一些分佈式和集羣技術也有一些接觸，只是研究得並不深入。比如分佈式服務框架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.1、高吞吐計算(High-throughput Computing)
有一類高性能計算，可以把它分成若干可以並行的子任務，而且各個子任務彼此間沒有什麼關聯。象在家搜尋外星人（ SETI@HOME – Search for Extraterrestrial Intelligence at Home ）就是這一類型應用。這一項目是利用Internet上的閒置的計算資源來搜尋外星人。SETI項目的服務器將一組數據和數據模式發給Internet上 參加SETI的計算節點，計算節點在給定的數據上用給定的模式進行搜索，然後將搜索的結果發給服務器。服務器負責將從各個計算節點返回的數據彙集成完整的 數據。因爲這種類型應用的一個共同特徵是在海量數據上搜索某些模式，所以把這類計算稱爲高吞吐計算。所謂的Internet計算都屬於這一類。按照 Flynn的分類，高吞吐計算屬於SIMD（Single Instruction/Multiple Data）的範疇。
3.2、分佈計算(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是自己有相應的機制實現的。
就到這裏吧，小寶鴿也是有點累了，準備先下班了~~~~~~~~