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

搜雲庫發表於2018-01-24
分散式

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

分散式和叢集區別？

分散式

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

常用的分散式就是在負載均衡伺服器後加一堆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


相關文章