分散式和集群區別？什麼是雲計算平台？分散式的應用場景？

分散式是指將一個業務拆分不同的子業務，分布在不同的機器上執行，集群是指多台伺服器集中在一起，實現同一業務，可以視為一台計算機，一個雲計算平台，就是通過一套軟體系統把分散式部署的資源集中調度使用。要應對大並發，要實現高可用，既需要分散式，也離不開集群。

分散式和集群區別？

分散式

分散式：是指將一個業務拆分不同的子業務，分布在不同的機器上執行。

常用的分散式就是在負載均衡伺服器後加一堆web伺服器，然後在上面搞一個緩存伺服器來保存臨時狀態，後面共享一個資料庫，

如圖所示:

這種環境下真正進行分散式的只是web server而已，並且web server之間沒有任何聯繫，所以結構和實現都非常簡單。

集群

集群：是指多台伺服器集中在一起，實現同一業務，可以視為一台計算機。

多台伺服器組成的一組計算機，作為一個整體存在，向用戶提供一組網路資源，這些單個的伺服器就是集群的節點。

兩個特點

可擴展性：集群中的服務節點，可以動態的添加機器，從而增加集群的處理能力。

高可用性：如果集群某個節點發生故障，這台節點上面運行的服務，可以被其他服務節點接管，從而增強集群的高可用性。

集群分類

常用的集群分類

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

高可用集群,普通兩節點雙機熱備，多節點HA集群。

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

常用的有 Nginx 把請求分發給後端的不同web伺服器，還有就是資料庫集群，負載均衡就是，為了保證伺服器的高可用，高並發。

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

簡稱HPC集群。這類集群致力於提供單個計算機所不能提供的強大的計算能力。

兩大能力

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

集群容錯：當我們的系統中用到集群環境,因為各種原因在集群調用失敗時，集群容錯起到關鍵性的作用。

例如 Dubbo 的集群容錯：

Failover Cluster

失敗自動切換，當出現失敗，重試其它伺服器，通常用於讀操作，但重試會帶來更長延遲。

Failfast Cluster

快速失敗，只發起一次調用，失敗立即報錯，通常用於非冪等性的寫操作，比如新增記錄。

Failback Cluster

失敗自動恢復，後台記錄失敗請求，定時重發，通常用於消息通知操作。

Forking Cluster

並行調用多個伺服器，只要一個成功即返回，通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。

簡單總結

分散式，從狹義上理解，也與集群差不多，但是它的組織比較鬆散，不像集群，有一定組織性，一台伺服器宕了，其他的伺服器可以頂上來。

分散式的每一個節點，都完成不同的業務，一個節點宕了，這個業務就不可訪問了。

1. 分散式是指將一個業務拆分不同的子業務，分布在不同的機器上執行。

2. 集群是指多台伺服器集中在一起，實現同一業務，可以視為一台計算機。

分散式的每一個節點，都可以用來做集群。而集群不一定就是分散式了。

什麼是雲計算平台？

一個雲計算平台，就是通過一套軟體系統把分散式部署的資源集中調度使用。要應對大並發，要實現高可用，既需要分散式，也離不開集群。

比如負載均衡，如果只是一台伺服器，這台宕機了就完蛋了。

分散式的難點，就是很多機器做存在依賴關係的不同活兒，這些活兒需要的資源、時間區別可能很大，某些機器還可能罷工，要怎麼樣才能協調好，做到效率最高，消耗最少，不出錯。

分散式的應用場景？

平時接觸到的分散式系統有很多種，比如分散式文件系統，分散式資料庫，分散式WebService，分散式計算等等，面向的情景不同，但分散式的思路是否是一樣的呢?

1.簡單的例子

假設我們有一台伺服器，它可以承擔1百萬/秒的請求，這個請求可以的是通過http訪問網頁，通過tcp下載文件，jdbc執行sql，RPC調用介面…，現在我們有一條數據的請求是2百萬/秒，很顯然伺服器hold不住了，會各種拒絕訪問，甚至崩潰，宕機，怎麼辦呢。

一台機器解決不了的問題，那就兩台。所以我們加一台機器，每台承擔1百萬。如果請求繼續增加呢，兩台解決不了的問題，那就三台唄。

這種方式我們稱之為水平擴展。如何實現請求的平均分配便是負載均衡了。

另一個栗子，我們現在有兩個數據請求，數據1 90萬，數據2 80萬，上面那台機器也hold不住，我們加一台機器來負載均衡一下，每台機器處理45萬數據1和40萬數據2，但是平分太麻煩，不如一台處理數據1，一台處理數據2，同樣能解決問題，這種方式我們稱之為垂直拆分。

水平擴展和垂直拆分是分散式架構的兩種思路，但並不是一個二選一的問題，更多的是兼并合用。下面介紹一個實際的場景。這也是許多互聯網的公司架構思路。

2.實際的例子

我此時所在的公司的計算機系統很龐大，自然是一個整的分散式系統，為了方便組織管理，公司將整個技術部按業務和平台拆分為部門，訂單的，會員的，商家的等等，每個部門有自己的web伺服器集群，資料庫伺服器集群，通過同一個網站訪問的鏈接可能來自於不同的伺服器和資料庫，對網站及底層對資料庫的訪問被分配到了不同的伺服器集群,這個便是典型的按業務做的垂直拆分，每個部門的伺服器在hold不住時，會有彈性的擴展，這便是水平擴展。

在資料庫層，有些表非常大，數據量在億級，如果只是純粹的水平的擴展並不一定最好，如果對錶進行拆分，比如可以按用戶id進行水平拆表，通過對id取模的方式，將用戶劃分到多張表中，同時這些表也可以處在不同的伺服器。按業務的垂直拆庫和按用戶水平拆表是分散式資料庫中通用的解決方案。

比如 Mycat 開源分散式資料庫中間件 http://www.mycat.io/

3.分散式一致性

分散式系統中，解決了負載均衡的問題後，另外一個問題就是數據的一致性了，這個就需要通過同步來保障。根據不同的場景和需求，同步的方式也是有選擇的。

在分散式文件系統中，比如商品頁面的圖片，如果進行了修改，同步要求並不高，就算有數秒甚至數分鐘的延遲都是可以接受的，因為一般不會產生損失性的影響，因此可以簡單的通過文件修改的時間戳，隔一定時間掃描同步一次，可以犧牲一致性來提高效率。

但銀行中的分散式資料庫就不一樣了，一丁點不同步就是無法接受的，甚至可以通過加鎖等犧牲性能的方式來保障完全的一致。

在一致性演算法中paxos演算法是公認的最好的演算法，Chubby、ZooKeeper 中Paxos是它保證一致性的核心。這個演算法比較難懂，我目前也沒弄懂，這裡就不深入了。

Contact

• 作者：鵬磊
• 出處：http://www.ymq.io/2018/01/23/Distributed-cluster/
• Email：admin@souyunku.com
• 版權歸作者所有，轉載請註明出處
• Wechat：關注公眾號，搜雲庫，專註於開發技術的研究與知識分享

http://weixin.qq.com/r/0UwmPsnEJJRbrY1d9xnD (二維碼自動識別)