分散式與集群的區別是什麼？

12-27

小飯店原來只有一個廚師，切菜洗菜備料炒菜全乾。後來客人多了，廚房一個廚師忙不過來，又請了個廚師，兩個廚師都能炒一樣的菜，這兩個廚師的關係是集群。為了讓廚師專心炒菜，把菜做到極致，又請了個配菜師負責切菜，備菜，備料，廚師和配菜師的關係是分散式，一個配菜師也忙不過來了，又請了個配菜師，兩個配菜師關係是集群

分散式：一個業務分拆多個子業務，部署在不同的伺服器上
集群：同一個業務，部署在多個伺服器上

集群是個物理形態，分散式是個工作方式。

只要是一堆機器，就可以叫集群，他們是不是一起協作著幹活，這個誰也不知道；一個程序或系統，只要運行在不同的機器上，就可以叫分散式，嗯，C/S架構也可以叫分散式。

集群一般是物理集中、統一管理的，而分散式系統則不強調這一點。

所以，集群可能運行著一個或多個分散式系統，也可能根本沒有運行分散式系統；分散式系統可能運行在一個集群上，也可能運行在不屬於一個集群的多台（2台也算多台）機器上。

分散式是指將不同的業務分布在不同的地方。而集群指的是將幾台伺服器集中在一起，實現同一業務

我個人理解：集群強調的是任務的同一性，分散式強調的是差異性。例如同樣是負責文件傳輸的伺服器，對終端用戶而言它只知道文件傳到伺服器上了，不在乎後台是幾台伺服器，分布在那些機房。對於後台管理人員而言，同樣是文件上傳我可以在上海放置伺服器處理上海地區的請求，北京放置伺服器處理北京的請求，最終實現全部地區用戶可上傳文件的任務，所以從這個角度來看是分散式的。另一方面，上海的伺服器可能有多台，同時處理上海來的請求，只是前端做了負載均衡，其內部運行邏輯什麼的完全是另外一台的clone,有一台掛掉了對整體業務無影響，所以從這個角度看是集群。如果北京的伺服器全掛了，那麼北京的用戶就沒得玩了，從分散式的角度看對此是無能為力的，如果在此情況下我將北京的請求轉到上海，實現城市間的集群概念，那麼就可handle 這個問題了。不過目前好像集群的概念用的比較范了，你對用戶說他的文件上傳到了伺服器集群也是ok的，至於內部是怎麼個架構怎麼個分布都無所謂了。

分散式是相對中心化而來，強調的是任務在多個物理隔離的節點上進行。中心化帶來的主要問題是可靠性，若中心節點宕機則整個系統不可用，分散式除了解決部分中心化問題，也傾向於分散負載，但分散式會帶來很多的其他問題，最主要的就是一致性。
集群就是邏輯上處理同一任務的機器集合，可以屬於同一機房，也可分屬不同的機房。分散式這個概念可以運行在某個集群裡面，某個集群也可作為分散式概念的一個節點。
一句話，就是：「分頭做事」與「一堆人」的區別

按照我的理解，集群是解決高可用的，而分散式是解決高性能、高並發的

分散式強調機器間的協作，其重點是任務可拆分，如某個任務需要一個機器運行10個小時，將該該任務用10台機器的分散式跑，可能2個小時就跑完了。（子任務之間有依賴關係）。

集群偏重干同一樣一件事的一組機器。如某個任務需要一個機器運行10個小時，那任務放到處理該任務的集群上還是需要10個小時。假如有10個這樣的任務，放到同一個集群上，仍然需要10個小時。

有一天，隔壁小王睡前突然有一個大膽的插法，哦不~ 大膽的想法，他要做一個在線B2C的美女網站，突然發現接下來要發了，可以贏取白富美了，不過他又想到了一個問題：

「想法都有了，就差一個程序員了」！

翻了一會通訊錄後發現了樓下的小明就是個程序員啊！於是也不管幾點就直接從床上跳起來，穿著拖鞋跑到樓下猛敲小明的房門。

小明這時候正在寫代碼，被連續的敲門聲嚇得寫了一個bug後就去開門了。

「什麼事啊？」

「呀，我是你樓上的小王啊，你還沒睡啊？有事找你有事找你」

小王不管不顧的走進去，小明一陣錯愕！

「小明」，小王放低了聲音，「我有一個項目，絕對能發，現在就差開發了，聽說你的技術很牛逼！」

「什麼項目？」，小明被小王的神秘語氣和一種不知哪來的自信引起了興趣！

「一個B2C的美女網站，用戶可以購買美女的時間，比如買11月15號的下午14：00-16：00，然後下訂單，美女可以在這兩個鍾陪用戶讀書學習 ……」小王繪聲繪色，小明卻一臉無奈。。

小王知道小明的意思，就繼續吹：「到時一定賺錢的，你就是我的合伙人啊，你拿30%」。

小明不為所動…

這時候小王冒出了些許冷汗，轉念一想，做出了猥瑣的表情說道：「我可是樓上小王哦！」

…

總之，在小王的威逼利誘下，小明勉強答應了！

小明跟小王聊了5個晚上的需求，有時候聊著聊著就一起睡著了，慢慢理清了思路，就開始幹了。

他像以前的開發那樣，建立一個web工程，不斷往web裡邊添加功能，比如訂單功能，用戶管理功能，商品信息管理功能等都丟到web工程裡邊。

在小王的催促和監督下，經過兩個多月，小明終於搞完第一個初始版本！

小明和小王都測試了一遍發現沒什麼問題，就打算弄個伺服器，然後把web項目和資料庫都扔到一個tomcat里去。

上線了！！！

小王很開心，看到了自己的想法實現了，並且已經在網上可以找到！

過了好幾天，網站的用戶量是2，也就是只有他們2個。小王開始急了 - -

小王發現推廣很重要，於是去跟他爸爸拿了幾百萬投放廣告，他爸爸剛開始不肯，說不懂互聯網，於是小王把網站發給他爸看，他爸就同意了。

小王有錢之後，就去找廣告商了，於是慢慢的電視上的綜藝節目有了他的美女網站的廣告了！

理所當然的用戶量開始越來越高了，小明發現，伺服器崩了！！

並發量太大，小明覺得一個tomcat已經不行了，於是小明就告訴小王，咱們用戶量越來越多了，一個伺服器不行，買多兩台伺服器吧，小王聽到用戶量增加，開心的答應了。

小明把項目在每個伺服器裡邊都放了一份，然後用nginx代理轉發。

就這樣可以頂了一段時間…

最近小王在後台上架了一個非常漂亮的美女，導致太多用戶訪問，伺服器又崩了…

小明對小王說：「我們得加強一下伺服器配置了，把帶寬，內存和cpu都升級吧！」

於是，又頂了一段時間…

過不久又崩了！

小王開始不爽了，對小明說：「怎麼搞的？怎麼伺服器老是不行？？」

小明說：「我他媽怎麼知道你是個富二代？一開始以為你是鬧著玩的，誰知道用戶量會增多？」

小王發現小明有點生氣了，他想著不能得罪程序員，於是輕聲說：「那怎麼辦？」

「我得重構了！每個tomcat都放著整個web工程，後台訪問也就我們兩個，沒有並發的問題，浪費資源了。模塊之間耦合度太高了，其中一個功能升級其他的也都得升級，系統擴展性也差，不能夠靈活的去部署」,小明如是說！

小王有點似懂非懂的問：「那怎麼重構呢？」

「用分散式！我們把整個項目工程拆分成多個子項目，每個子項目負責自己的功能，例如訂單這個功能就是一個單獨的系統項目，會員系統也是一個單獨的系統。」小明邊說邊在紙上畫了一張圖：

小王依然似懂非懂的問：「這樣比之前有多好？」

「這樣的話，我們把每個模塊都拆分出來，可以靈活的部署了，比如美女商品信息這個模塊被訪問的量比較大，那麼我們就可以單獨對這個模塊進行服務性能的提升，不用全部都一起提升。也降低了代碼的耦合度，模塊之間互不影響，這樣如果以後有人加入開發，他只要負責他的模塊去開發就可以了，合作也高效！」小明說道。

「那有什麼缺點沒？」

「有吧，就是各個模塊之間需要通信，這時候需要開發介面，增加了些工作量！不過這是值得，總比花錢去買更多伺服器配置好吧！」

「恩，有道理有道理！」

於是小明就這樣開始重構了他的項目，慢慢的項目的穩定性比之前的好多了。

過了6個月，項目開始盈利了，於是小王開始招兵買馬，把小明踢出去。

（哈哈，沒有啦，開玩笑的，最後他們在一起了！）

歡迎0-3歲的developer來我的公眾號：肯定會

我和那些喜歡軟體技術的小夥伴在那裡等著你！

普通的軟體是運行在一台物理機器上的，比如一個app或一個操作系統（如linux）；
而分散式系統則是這樣一種軟體系統：它運行在網路上，網路對於分散式系統就如同單台計算機對於普通軟體。
集群則是一組物理計算機的組合，組合起來的目標得看具體場合，比如有的是為了提高可用性，有的是為了提高性能，有的是為了應對高並發。集群內的計算機之間使用什麼方式進行協作，得看它們用的是什麼軟體系統：既可能是分散式的系統也可能是普通的軟體系統。

根據所查資料，分散式是不同的伺服器節點完成不同的任務，集群是不同的伺服器對外提供一致的服務

畫了一上午，麻煩點個贊～

下面就正經解釋下三種結構的區別吧～

單機結構

我想大家最最最熟悉的就是單機結構，一個系統業務量很小的時候所有的代碼都放在一個項目中就好了，然後這個項目部署在一台伺服器上就好了。整個項目所有的服務都由這台伺服器提供。這就是單機結構。

那麼，單機結構有啥缺點呢？我想缺點是顯而易見的，單機的處理能力畢竟是有限的，當你的業務增長到一定程度的時候，單機的硬體資源將無法滿足你的業務需求。此時便出現了集群模式，往下接著看。

集群結構

集群模式在程序猿界有各種裝逼解釋，有的讓你根本無法理解，其實就是一個很簡單的玩意兒，且聽我一一道來。

單機處理到達瓶頸的時候，你就把單機複製幾份，這樣就構成了一個「集群」。集群中每台伺服器就叫做這個集群的一個「節點」，所有節點構成了一個集群。每個節點都提供相同的服務，那麼這樣系統的處理能力就相當於提升了好幾倍（有幾個節點就相當於提升了這麼多倍）。

但問題是用戶的請求究竟由哪個節點來處理呢？最好能夠讓此時此刻負載較小的節點來處理，這樣使得每個節點的壓力都比較平均。要實現這個功能，就需要在所有節點之前增加一個「調度者」的角色，用戶的所有請求都先交給它，然後它根據當前所有節點的負載情況，決定將這個請求交給哪個節點處理。這個「調度者」有個牛逼了名字——負載均衡伺服器。

集群結構的好處就是系統擴展非常容易。如果隨著你們系統業務的發展，當前的系統又支撐不住了，那麼給這個集群再增加節點就行了。但是，當你的業務發展到一定程度的時候，你會發現一個問題——無論怎麼增加節點，貌似整個集群性能的提升效果並不明顯了。這時候，你就需要使用微服務結構了。

分散式結構

先來對前面的知識點做個總結。

從單機結構到集群結構，你的代碼基本無需要作任何修改，你要做的僅僅是多部署幾台伺服器，每台伺服器上運行相同的代碼就行了。但是，當你要從集群結構演進到微服務結構的時候，之前的那套代碼就需要發生較大的改動了。所以對於新系統我們建議，系統設計之初就採用微服務架構，這樣後期運維的成本更低。但如果一套老系統需要升級成微服務結構的話，那就得對代碼大動干戈了。所以，對於老系統而言，究竟是繼續保持集群模式，還是升級成微服務架構，這需要你們的架構師深思熟慮、權衡投入產出比。

OK，下面開始介紹所謂的分散式結構。

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

舉個例子，假設需要開發一個在線商城。按照微服務的思想，我們需要按照功能模塊拆分成多個獨立的服務，如：用戶服務、產品服務、訂單服務、後台管理服務、數據分析服務等等。這一個個服務都是一個個獨立的項目，可以獨立運行。如果服務之間有依賴關係，那麼通過RPC方式調用。

這樣的好處有很多：

系統之間的耦合度大大降低，可以獨立開發、獨立部署、獨立測試，系統與系統之間的邊界非常明確，排錯也變得相當容易，開發效率大大提升。
系統之間的耦合度降低，從而系統更易於擴展。我們可以針對性地擴展某些服務。假設這個商城要搞一次大促，下單量可能會大大提升，因此我們可以針對性地提升訂單系統、產品系統的節點數量，而對於後台管理系統、數據分析系統而言，節點數量維持原有水平即可。
服務的復用性更高。比如，當我們將用戶系統作為單獨的服務後，該公司所有的產品都可以使用該系統作為用戶系統，無需重複開發。

還不趕緊關注我的公眾號！

Distributed是針對用戶/終端來講的，把Job送到地理上分散的sever(i.e. 網格類)上協同作業，然後合併計算結果。
Cluster是把很多的server捆綁串並，以infiniband實現高速內部互聯網路，組成HPC. 從而支持多用戶的並行計算。

在這裡我也發表一下自己的一些拙見，看到大家這麼多的回復，我思考，加入一個企業用一套體量很大的系統，需要高效率處理任務的目標時，我覺得採用分散式+集群的模式是不是應該是最佳的。也就是說，先用分散式把這套系統進行負載均衡，即把各個功能模塊進行拆分（也就是分散式概念），然後在拆分的基礎上增加集群。

Google是個好東西，維基百科也是個好東西。要考究的話，當然是正兒八經的論文實在，但是要弄明白個大概，Google足矣。

先搬維基百科的定義：

在計算機科學中，分散式計算（英語：Distributed computing），又譯為分散式運算。這個研究領域，主要研究分散式系統（Distributed system）如何進行計算。分散式系統是一組電腦（computer），通過網路相互鏈接傳遞消息與通信後並協調它們的行為而形成的系統。組件之間彼此進行交互以實現一個共同的目標。把需要進行大量計算的工程數據分區成小塊，由多台計算機分別計算，再上傳運算結果後，將結果統一合併得出數據結論的科學。

--------

計算機集群簡稱集群是一種計算機系統，它通過一組鬆散集成的計算機軟體和/或硬體連接起來高度緊密地協作完成計算工作。在某種意義上，他們可以被看作是一台計算機。集群系統中的單個計算機通常稱為節點，通常通過區域網連接，但也有其它的可能連接方式。集群計算機通常用來改進單個計算機的計算速度和/或可靠性。一般情況下集群計算機比單個計算機，比如工作站或超級計算機性能價格比要高得多。
計算機集群的特點：
1. 通過多台計算機完成同一個工作。達到更高的效率。
2. 兩機或多機內容、工作過程等完全一樣。如果一台死機，另一台可以起作用。

所以，據此可以認為（只是據此），分散式就是將一個任務分攤到不同的節點共同完成，這幾個節點是協同工作的，存在互相依賴的關係，其中一個掛掉了有可能使得其他節點都不能工作；而集群就是多個節點執行相同的任務，互不干擾，就像飯堂的窗口，每個窗口的職能都是一樣的，在哪個窗口都能達到目的，隨便關了哪個窗口都可以，只要還有窗口可用，客人就能排隊打飯。

正如上文的引文，集群要解決的是可靠性，而分散式的主要工作是分解任務，將職能拆解。

我發現一般的案例都可以用飯店的場景類比

回答這個問題前，首先我們先了解一下分散式和集群的由來。在開始的時候，網站都是一個簡單的架構，例如LAMP的架構，就在一台伺服器上部署了各種應用程序，訪問的人少，伺服器能輕鬆應對。當請求量增大的時候，伺服器的資源已經扛不住這種壓力了，從而將相關的應用放在不同的伺服器上，提供更好的性能，當請求量進一步增大的時候，應用jboss和mysql可能都不能抗住這種請求壓力了，從而也就引出了集群的由來。

集群主要的使用場景是為了分擔請求的壓力，也就是在幾個伺服器上部署相同的應用程序，來分擔客戶端請求，當壓力進一步增大的時候，可能在需要存儲的部分，mysql無法面對很多的寫壓力，因為在mysql做成集群之後，主要的寫壓力還是在master的機器上面，其他slave機器無法分擔寫壓力，從而這個時候，也就引出來分散式。

分散式的主要應用場景是單台機器已經無法滿足這種性能的要求，必須要融合多個節點，並且節點之間是相關之間有交互的，相當於在寫mysql的時候，每個節點存儲部分數據，也就是分散式存儲的由來，在存儲一些非結構化數據，例如靜態文件，圖片，pdf，小視頻，這些也就是分散式文件系統的由來。

廢話了那麼多，那麼到底分散式和集群有啥區別呢？

集群和分散式都是由多個節點組成，但是集群之間的通信協調基本不需要，而分散式各個節點的通信協調必不可少。

集群主要是為了應對請求壓力的分擔，從而有了LB，負載均衡集群；為了應對可用性，從而有了HA，高可用性集群；為了更強的性能，從而有了HP，高性能集群；為了高並發大規模性能，從而有分散式系統集群。

分散式是分任務並發處理；集群是同一個任務一起處理。

分散式：不同的業務模塊部署在不同的伺服器上或者同一個業務模塊分拆多個子業務，部署在不同的伺服器上，解決高並發的問題
集群：同一個業務部署在多台機器上，提高系統可用性

集群一般被分為三種類型，高可用集群如RHCS、LifeKeeper等，負載均衡集群如LVS等、高性能運算集群;分散式應該是高性能運算集群範疇內。