在介紹叢集模式和分散式架構之前，我們先說說大家最熟悉的單機結構，將所有的程式碼都放在一個專案，再將這個專案部署在一臺伺服器上，整個專案所有的服務都由這臺伺服器提供，這就是單機結構。在訪問量不高的情況下，單體架構是可以承受的，但是單機的處理能力畢竟是有限的，當我們的業務增長到一定程度的時候，單機的硬體資源將無法滿足我們的業務需求，此時便衍生出了叢集模式。

簡單來說叢集就是將同一個業務部署在多個伺服器上，當單機處理到達瓶頸的時候，我們就把單機專案複製幾份，構成一個“叢集”。叢集中的每臺伺服器叫做這個叢集的一個“節點”，每個節點都提供相同的服務，這樣系統的處理能力就相當於提升了好幾倍。那麼在效率提高的同時是如何來解決訪問哪臺機器的分配問題呢？這時便出現了負載均衡伺服器，它可以使得每個節點的壓力都比較平均，使用者的所有請求都先交給負載均衡伺服器，然後由負載均衡伺服器根據當前所有節點的負載情況，決定將這個請求交給哪個節點處理。一般採用Nginx作為負載均衡伺服器。

叢集結構的優點是系統擴充套件非常容易。隨著業務的發展，只需要給這個叢集增加節點即可。但是，當業務發展到一定程度時，無論怎麼增加節點，整個叢集的效能提升效果好像都不明顯了。此時，便衍生出了分散式。

簡單來說分散式就是將一個業務分拆成多個子業務，部署在不同的伺服器上，每臺伺服器都承擔不同的責任。這樣分模組部署最主要的優點是實現業務隔離，也就是說個別功能出現問題或者發生改進都不會影響其他模組，就算個別模組掛掉了，其他模組也能夠不受影響繼續運作。系統之間的耦合度大大降低，可以獨立開發、獨立部署、獨立測試，系統與系統之間的邊界非常明確，排錯也變得相當容易，開發效率大大提升，從而系統更易於擴充套件，並且可以針對性地擴充套件某些服務。

從單機結構到叢集模式，程式碼基本無需做修改，我們要做的僅僅是多部署幾臺伺服器，讓每臺伺服器上執行相同的程式碼。分散式就是將一個完整的系統，按照業務功能拆分成一個個獨立的子系統，這些子系統能夠獨立執行在web容器中，它們之間通過RPC方式通訊。

總體來說，叢集強調的是高可用，分散式強調的是多業務協作。

叢集比較好理解，多個同等物理服務聯合提供服務，高可用，提升吞吐量。

分散式就沒那麼簡單吧，把一個系統分解碎片就是分散式？

分散式比較早出現在資料庫，檔案系統。

在資料庫領域，分散式資料庫已經研究幾十年了，一直沒啥突破性進展。理想模式的分散式資料庫是多個寫入點，聯合組成資料庫，能夠跨越地理區域，外部是感知不到資料到底儲存在哪。

這裡面涉及致命問題是分散式事務，資料庫分散式資料有現成的方案，2階段提交，問題是效能太差。所以基本沒人敢用。

分散式檔案系統

其實檔案系統這塊有個方案，弄個高速共享磁碟，機房內所有伺服器共享該裝置，實現檔案系統層面高速共享。這個方案主要問題出在物理裝置太貴，可支援機器有限。

分散式檔案系統，主要還是hdfs為代表。配合hadoop出現。典型特徵還是不知道資料在哪。甚至不知道資料咋組成的。hdfs使用很嚴謹機制來確保寫入正確性。

hadoop的mapreduce也是分散式的一種，只是限定在特定框架內的分散式。

分散式系統，早先出現過soa系統，2010年的一個號稱soa系統，介面使用soap，核心使用jbpm jms完成通訊和協調工作，在8個伺服器上完成業務切割，將具體業務模組封裝在jbpm，剩下就是利用jbpm框架在8個物理服務上交替完成業務模組，一條業務流程，全走完可能隨機分佈在不同的服務上，這個和更早出現的叢集不一樣，叢集是一個流程會集中在一個物理服務上。

再後來微服務盛行，將業務模組做成微服務，服務組合利用rest或者mq。將先前soa的8個巨型物理伺服器變成n個doker映象。驅動業務模組的jbpm不需要了，可以通過更自由的方式組合使用這些微服務。

分散式焦點還是事務性，看過一個資料，這塊目前來說還無法真正解決問題，cap原理無法打破。

平行計算和分散式還有叢集的區分，以前平行計算也叫高效能運算，是在大型機器上用特定演算法和框架完成大型工程計算。

不過叢集和分散式系統有時也能起到平行計算的效果，比如一個計算節點無法短時間處理10000個任務，那就擴機器，橫向擴大叢集，100個節點計算，時間可縮小到1/100。而hadoop也有類似效果，一個計算節點無法完成海量計算，將其分解後，分散到多個計算節點將計算時間變成可行。

還有主從模式算分散式嗎？

典型資料庫的主從模式算嗎？我個人覺得不算，mysql的分散式資料庫專指mysql cluster，是在ndb基礎上搭建。

那資料庫分片算嗎？

比如mongo的分片算嗎？

我個人覺得不算。

個人覺得分散式這個被弄的很凌亂。所以看到不同系統不同資料不同時期，給的概念和定義都有差異。本人見識不足，錯誤的理解之處見諒。

分散式和叢集不是同一個維度的概念。

叢集是個物理形態，分散式是個工作方式。只要是一堆機器，就可以叫叢集，他們是不是一起協作著幹活，這個誰也不知道；一個程式或系統，只要執行在不同的機器上，就可以叫分散式，嗯，C/S架構也可以叫分散式。叢集一般是物理集中、統一管理的，而分散式系統則不強調這一點。所以，叢集可能執行著一個或多個分散式系統，也可能根本沒有執行分散式系統；分散式系統可能執行在一個叢集上，也可能執行在不屬於一個叢集的多臺（2臺也算多臺）機器上。

個人觀點這個是兩個維度的東西，分散式應該和SOA相提並論。叢集是分散式上層建築，通常和負載均衡一起出現。

在BAT與同事們交流過，分散式已經逐漸成為面試時必不可少的問題了。瞭解面試者對分散式的理解，一方面可以側面驗證其過去工作的規模，另一方面可以測試他對架構設計方面的功底。

但是叢集相對來說，在面試中提到的較少，因此很多人對分散式與叢集的區別都不是很清楚。

接下來，我們將從N個方面來分析他們的區別。

叢集傾向於物理概念，即多臺機器組成一個叢集。這多臺機器是否有合作關係並不能保證，比如我們會說我們公司的一個規模為1000臺機器的物理叢集部署在昌平，但是這1000臺機器可能是給公司內不同的平臺提供服務，但是從物理角度，由於都部署在一起，在同一個機房，就可以稱之為叢集。

分散式傾向於邏輯概念，即多個節點或程式為了一個共同的目標，部署在一個或者多個物理機器上。舉個例子，一臺物理機上裝了一個Nginx，它連線的兩個Tomcat也在這臺物理機上，但是這個Nginx代表的服務，就可以稱之為分散式。當然，為了安全性，穩定性等原因，我們並不建議把分散式部署在一個物理節點上。

叢集除了可以用來表示多個物理機器，還可以表示一種“冗餘”的理念，即通過部署多個同樣功能的節點，來實現擴充套件性與可用性的提升。舉個例子，通過在不同節點上部署兩個同樣功能的server，來這樣就算其中一個節點宕機，也能保證服務的可用性。而擴充套件性，比如一個server的qps可用承擔到2000，但是隨著使用者群體的增加，qps需要達到3000，那麼我們就可以通過增加一個Tomcat節點的方式來實現擴容。

分散式的分解與微服務的概念有點相近，即把一個系統的功能分佈在不同節點上，每個節點都承擔了不同的責任，這樣分模組部署最主要的優勢是業務隔離，即個別功能的問題或者改進不會影響其他模組，這樣就算個別模組掛掉，其他模組也能夠繼續運作。舉個例子，前些年春晚搶紅包的時候，曾經由於瞬時間請求量太大導致把微信和支付寶給弄癱瘓了，但是大家都知道，癱瘓的只是紅包部分的功能，微信的資訊功能並不受影響，這就是分散式的好處。

「叢集」的核心在「冗餘」，通過冗餘來提高系統的「可用性」，附帶影響了系統「容量」。

「分散式」的核心在「拆分」，通過拆分後的分工合作，提高系統的「響應」和「容錯能力」，附帶影響了「可用性」。

區分「叢集」和「分散式」的方法就是這一組系統/元件之間是「冗餘」關係，還是「分工合作」關係。

假設題主是個有老婆的程式設計師！再假設題主的老婆開了一家小吃店！

因為是小本生意，初期收銀、服務、做菜、打掃都是你老婆一個人做。這就是「單機系統」。

但是你老婆也不是超人，偶爾會生個病，或者有其他事情，這個時候就沒法開店了，也就是說「系統停止對外提供服務了」！

為了減少關店的時間，你在老婆有事的時候，就去幫忙開店。這時你和你老婆就組成了「主備」。你老婆是「主」，你是「備」！

後來生意越做越好，你老婆一個人扛不住了。你琢磨著幹軟體沒前途，還不如和老婆開夫妻店去。於是你就辭職和老婆一起開店了。這時你和你老婆就組成了「叢集」。你和你老婆都做收銀、服務、做菜、打掃的工作，誰有事了，店也能開，只是服務的人數會(容量)相對的減少。

再後來，生意更好了，於是你招了個服務員，你和你老婆就不再做服務的事情了。現在服務員、你和你老婆就組成了「分散式」！而你和你老婆之間還是「叢集」的關係。

再再後來，一個服務員也不夠了，如果這個服務員請假了，生意又不好做了（單點問題），於是你又招了個服務員。這兩個服務員又組成了「叢集」！

最後你生意做得很紅火，你招了廚師、收銀、服務員、洗碗工、清潔員。你帶著你老婆出去浪了～

以下的解釋都是太片面了，把分散式=垂直切分、叢集=水平拓展。其實分散式是邏輯概念，叢集是物理概念。兩者結合在一起才是真正的分散式。不管是垂直切分和水平拓展都要考慮分散式帶來很多的問題，資料不一致，事務失敗、可用性底等，也就是CAP原理，如果要詳細闡述就比較複雜了

叢集和分散式，兩者的區別還是挺大的，我就按照自己的理解，向大家解釋一下，如果有不對的地方，歡迎大家留言討論。（回答過類似的問題，不過每次回答的時候，都有新的收穫和感悟可以分享）

一個業務，部署在多臺伺服器上，這就是叢集。這裡的一個業務，可以直接看做一個程式包。

提到叢集，就不得不說一下負載均衡，這兩個概念一起舉個例子：

公司開發了一個網上商城，類似於T寶，顧客可以在上面瀏覽商品、加入購物車、支付，完成整個的購物流程。

公司買了一臺伺服器，把這套程式部署上去，可以滿足一千個人同時線上購物。

把一個業務，拆分成多個業務，然後部署到不同的伺服器上，這就是分散式。

還是舉例子說明：

公司的網上商城，拆分成兩個系統：商品系統和支付系統，使用者在商品系統上完成瀏覽商品、加入購物車的動作，在支付系統上完成支付動作（當然使用者是無法感知到是在兩個系統上完成的操作），這就是分散式。

當然，還能繼續拆，例如拆出來：使用者系統、積分系統等等等等。

那麼分散式的好處是什麼？公司說，我們再做一個二手交易平臺，類似於X魚，這時候使用者系統、支付系統就可以複用了，做到了服務複用。

兩者同城是結合一起使用的，比如商品系統部署五臺，支付系統部署五臺，前面各自掛負載均衡，這樣就算有單個伺服器Down掉，也不會對整個業務流程造成影響。

從工作形式來說：

分散式是將一個業務分拆為多個子業務，部署在不同的伺服器上。

叢集是將多臺伺服器集中在一起，實現同一業務。

分散式是研究如何把一個需要非常巨大的計算能力才能解決的問題分成許多小的部分，然後把這些部分分配為許多計算機進行處理，最後把這些計算結果綜合起來得到最終的結果。

分散式是以縮短單個任務的執行時間來提升效率的，任務具有差異性。

叢集是一組計算機作為一個整體向用戶提供一組網路資源，這些單個的計算機系統就是叢集的節點。一個理想的叢集是，使用者從來不會意識到集群系統底層的節點，在他們看來，叢集是一個系統，而非多個計算機系統，並且集群系統的管理員可以隨意增加和刪改集群系統的節點。

叢集是以提高單位時間內執行的任務數來提升效率的，任務具有同一性。

分散式：

橫向擴充套件性強

橫向可擴充套件性是指通過增加伺服器數量來提升整體效能，縱向可擴充套件性是指提升每臺伺服器效能進而提升總體效能。縱向可擴充套件性的上限非常明顯，因為單臺伺服器的效能不可能無限提升，而橫向可擴充套件性的上限空間比較大，分散式又恰恰總能很方便地增加伺服器。

這是分散式系統的突出特點，成本低廉的PC伺服器組成的分散式，在效能方面能達到超越大型機的處理效能，在成本上遠低於大型機。

網路開銷是分散式系統最大的瓶頸。

叢集：

可擴充套件性

叢集的效能不限於單一的服務實體，新的服務實體可以動態地加入到叢集，從而增強叢集的效能。

高可用性

在叢集中，同樣的服務可以由多個服務實體提供，如果一個服務實體失敗了，另一個服務實體會接管失敗的服務實體，服務實體冗餘保證了錯誤恢復能力，增強了系統的可用性。

負載均衡

負載均衡能把任務比較均衡地分佈到叢集環境下的計算和網路資源。

分散式中的每一個節點，可以做高可用叢集，這樣可以保證分散式每個節點可用。而叢集並不一定就是分散式的。

簡單來解釋：

一個任務，只有一個伺服器來執行，這個伺服器會累成狗；（單機結構）

多個累成狗的伺服器組合在一起執行，就可以叫叢集，他們是不是一起協作著幹活，這個誰也不知道；（叢集結構）

基因優化整合之後，多個伺服器被拆分到執行在不同的機器上，就像一群小小的伺服器一起工作，（分散式結構）

要充分理解這個概念，首先先明白什麼是單機結構：

普通的軟體是執行在一臺物理機器上的，一個系統業務量很小的時候，可以將所有的程式碼都放在一個專案中，然後部署在一臺伺服器上，這臺伺服器提供整個專案所有的服務。單機結構的啥缺點顯而易見，因為它的處理能力是有限的，當業務增長到一定程度的時候，單機的硬體資源將無法滿足。

此時便出現了叢集模式，單機處理到達瓶頸的時候，你就把單機複製幾份，這樣就構成了一個“叢集”。叢集中每臺伺服器就叫做這個叢集的一個“節點”，所有節點構成了一個叢集。每個節點都提供相同的服務，那麼這樣系統的處理能力就相當於提升了好幾倍。

分散式結構就是將一個完整的系統，按照業務功能，把一個服務系統拆分成一個個獨立的子系統，在分散式結構中，每個子系統就被稱為“服務”。這些子系統能夠獨立執行在web容器中，它們之間通過RPC方式通訊。

如題，分散式和叢集的區別是什麼？

喲喲簡單總結一句話：分散式是“並聯”工作的，叢集是“串聯”工作的。

下面喲喲來具體介紹一下兩者的區別：

1、從概念上就可以看出兩者最主要的區別就是分散式是將一種業務拆分成多個子業務部署在多臺伺服器上，進而對外提供服務；而叢集就是將多臺伺服器組合在一起提供同一種服務；

2、叢集強調在多臺伺服器位置集中，並且容易統一管理；而分散式沒有具體要求，不論放置在哪個位置，只要通過網路連線起來就行；

總之，兩者最明顯的區別還是叢集是多臺伺服器做相同型別的任務，分散式是多臺伺服器協同做一種任務。