分布式資料庫集群

① 分布式資料庫 與 集群資料庫 之間的關系

分布式, 往往指數據被割裂, 分置不同地方
集群指, 在任何實例上, 看到的數據都是一致的.
兩者有非常大的不同.
mysql 做不了集群, 只能做分布. 可以認為你必須先知道數據在哪個mysql實例上.

② oracle資料庫的分布式和tomcat的集群式有什麼區別

分布式是架構部署模式的一種。分布式多用於描述架構設計上，當然現在有各種新用法。
集群是硬體部署模式的一種，是集中部署在一個機房裡的計算機群體的集中稱謂。
分布式網站集群系統是一種多網站架構模式，支持生成獨立網站、多個網站,完成各個網站橫向一體化和縱向一體化網站群的構建，主站、子站、網站間的信息可共享和信息互聯。
簡單的說：就是一個企業/個人可以像申請博客那樣自助建站，維護，更新，而分布式，就是把問題分開解決的意思，即系統分布在幾個不同伺服器上。

③ 分布式資料庫與資料庫集群的區別到底是什麼哪位高手幫忙解惑下~~~~~~~~~~跪求

來具體說說資料庫集群吧
集群主要分成三大類 （高可用集群， 負載均衡集群，科學計算集群）
高可用集群( 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://bbo.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://bbo.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，如果要修改，請配置<bbo:parameter key="hash.arguments" value="0,1" />

預設用160份虛擬節點，如果要修改，請配置<bbo:parameter key="hash.nodes" value="320" />

④ 資料庫中的集群和F5

分布式資料庫系統分布式資料庫系統有兩種：一種是物理上分布的，但邏輯上卻是集中的。這種分布式資料庫只適宜用途比較單一的、不大的單位或部門。另一種分布式資料庫系統在物理上和邏輯上都是分布的，也就是所謂聯邦式分布資料庫系統。由於組成聯邦的各個子資料庫系統是相對「自治」的，這種系統可以容納多種不同用途的、差異較大的資料庫，比較適宜於大范圍內資料庫的集成。
----- ----
分布式資料庫系統(DDBS)包含分布式資料庫管理系統(DDBMS)和分布式資料庫(DDB)。在分布式資料庫系統中，一個應用程序可以對資料庫進行透明操作，資料庫中的數據分別在不同的局部資料庫中存儲、由不同的 DBMS進行管理、在不同的機器上運行、由不同的操作系統支持、被不同的通信網路連接在一起。
一個分布式資料庫在邏輯上是一個統一的整體，在物理上則是分別存儲在不同的物理節點上。一個應用程序通過網路的連接可以訪問分布在不同地理位置的資料庫。它的分布性表現在資料庫中的數據不是存儲在同一場地。 更確切地講，不存儲在同一計算機的存儲設備上。 這就是與集中式資料庫的區別。從用戶的角度看，一個分布式資料庫系統在邏輯上和集中式資料庫系統一樣，用戶可以在任何一個場地執行全局應用。就好那些數據是存儲在同一台計算機上，有單個資料庫管理系統(DBMS)管理一樣，用戶並沒有什麼感覺不一樣。
分布式資料庫系統是在集中式資料庫系統的基礎上發展起來的，是計算機技術和網路技術結合的產物。分布式資料庫系統適合於單位分散的部門，允許各個部門將其常用的數據存儲在本地，實施就地存放本地使用，從而提高響應速度，降低通信費用。分布式資料庫系統與集中式資料庫系統相比具有可擴展性，通過增加適當的數據冗餘，提高系統的可靠性。在集中式資料庫中，盡量減少冗餘度是系統目標之一．其原因是，冗餘數據浪費存儲空間，而且容易造成各副本之間的不一致性．而為了保證數據的一致性，系統要付出一定的維護代價．減少冗餘度的目標是用數據共享來達到的。而在分布式資料庫中卻希望增加冗餘數據，在不同的場地存儲同一數據的多個副本,其原因是：①．提高系統的可靠性、可用性當某一場地出現故障時，系統可以對另一場地上的相同副本進行操作，不會因一處故障而造成整個系統的癱瘓。②．提高系統性能系統可以根據距離選擇離用戶最近的數據副本進行操作，減少通信代價，改善整個系統的性能。
分布式資料庫具有以下幾個特點：
(1)、數據獨立性與位置透明性。數據獨立性是資料庫方法追求的主要目標之一，分布透明性指用戶不必關心數據的邏輯分區，不必關心數據物理位置分布的細節，也不必關心重復副本（冗餘數據）的一致性問題，同時也不必關心局部場地上資料庫支持哪種數據模型．分布透明性的優點是很明顯的．有了分布透明性，用戶的應用程序書寫起來就如同數據沒有分布一樣．當數據從一個場地移到另一個場地時不必改寫應用程序．當增加某些數據的重復副本時也不必改寫應用程序．數據分布的信息由系統存儲在數據字典中．用戶對非本地數據的訪問請求由系統根據數據字典予以解釋、轉換、傳送．
(2)、集中和節點自治相結合。資料庫是用戶共享的資源．在集中式資料庫中，為了保證資料庫的安全性和完整性，對共享資料庫的控制是集中的，並設有DBA負責監督和維護系統的正常運行．在分布式資料庫中，數據的共享有兩個層次：一是局部共享，即在局部資料庫中存儲局部場地上各用戶的共享數據．這些數據是本場地用戶常用的．二是全局共享，即在分布式資料庫的各個場地也存儲可供網中其它場地的用戶共享的數據，支持系統中的全局應用．因此，相應的控制結構也具有兩個層次：集中和自治．分布式資料庫系統常常採用集中和自治相結合的控制結構,各局部的DBMS可以獨立地管理局部資料庫，具有自治的功能．同時，系統又設有集中控制機制，協調各局部DBMS的工作，執行全局應用。當然,不同的系統集中和自治的程度不盡相同．有些系統高度自治，連全局應用事務的協調也由局部DBMS、局部DBA共同承擔而不要集中控制，不設全局DBA,有些系統則集中控製程度較高，場地自治功能較弱。
(3)、支持全局資料庫的一致性和和可恢復性。分布式資料庫中各局部資料庫應滿足集中式資料庫的一致性、可串列性和可恢復性。除此以外還應保證資料庫的全局一致性、並行操作的可串列性和系統的全局可恢復性。這是因為全局應用要涉及兩個以上結點的數據．因此在分布式資料庫系統中一個業務可能由不同場地上的 多個操作組成．例如, 銀行轉帳業務包括兩個結點上的更新操作。這樣，當其中某一個結點出現故障操作失敗後如何使全局業務滾回呢？如何使另一個結點撤銷已執行的操作(若操作已完成或完成一部分）或者不必再執行業務的其它操作(若操作尚沒執行)？這些技術要比集中式資料庫復雜和困難得多，分布式資料庫系統必須解決這些問題．
(4)、復制透明性。用戶不用關心資料庫在網路中各個節點的復制情況，被復制的數據的更新都由系統自動完成。在分布式資料庫系統中，可以把一個場地的數據復制到其他場地存放，應用程序可以使用復制到本地的數據在本地完成分布式操作，避免通過網路傳輸數據，提高了系統的運行和查詢效率。但是對於復制數據的更新操作，就要涉及到對所有復制數據的更新。
(5)、易於擴展性。在大多數網路環境中，單個資料庫伺服器最終會不滿足使用。如果伺服器軟體支持透明的水平擴展，那麼就可以增加多個伺服器來進一步分布數據和分擔處理任務。
分布式資料庫的優點：
(1)具有靈活的體系結構 。
(2)適應分布式的管理和控制機構。
(3)經濟性能優越 。
(4)系統的可靠性高、可用性好 。
(5)局部應用的響應速度快。
(6)可擴展性好，易於集成現有系統。
分布式資料庫的缺點：
(1)系統開銷大，主要花在通信部分。
(2)復雜的存取結構，原來在集中式系統中有效存取數據的技術，在分成式系統中都不再適用。
(3)數據的安全生和保密性較難處理。
分布式資料庫系統的目標
分布式資料庫系統的目標，也就是研製分布式資料庫系統的目的、動機，主要包括技術和組織兩方面的目標．
1．適應部門分布的組織結構，降低費用。
使用資料庫的單位在組織上常常是分布的（如分為部門、科室、車間等等），在地理上也是分布的．分布式資料庫系統的結構符合部門分布的組織結構，允許各個部門對自己常用的數據存儲在本地，在本地錄入、查詢、維護，實行局部控制．由於計算機資源靠近用戶，因而可以降低通信代價，提高響應速度，使這些部門使用資料庫更方便更經濟。
2．提高系統的可靠性和可用性。
改善系統的可靠性和可用性是分布式資料庫的主要目標．將數據分布於多個場地，並增加適當的冗餘度可以提供更好的可靠性．一些可靠性要求較高的系統，這一點尤其重要．因為一個地出了故障不會引起整個系統崩潰．因為故障場地的用戶可以通過其它場地進入系統．而其它場地的用戶可以由系統自動選擇存取路徑，避開故障場地，利用其它數據副本執行操作，不影響業務的正常運行．
3．充分利用資料庫資源，提高現有集中式資料庫的利用率
當在一個大企業或大部門中已建成了若干個資料庫之後，為了利用相互的資源，為了開發全局應用，就要研製分布式資料庫系統．這種情況可稱為自底向上的建立分布式系統．這種方法雖然也要對各現存的局部資料庫系統做某些改動、重構，但比起把這些資料庫集中起來重建一個集中式資料庫，則無論從經濟上還是從組織上考慮，分布式資料庫均是較好的選擇．
4．逐步擴展處理能力和系統規模
當一個單位規模擴大要增加新的部門(如銀行系統增加新的分行，工廠增加新的科室、車間)時，分布式資料庫系統的結構為擴展系統的處理能力提供了較好的途徑：在分布式資料庫系統中增加一個新的結點．這樣做比在集中式系統中擴大系統規模要方便、靈活、經濟得多。
在集中式系統中為了擴大規模常用的方法有兩種：一種是在開始設計時留有較大的餘地．這容易造成浪費，而且由於預測困難，設計結果仍可能不適應情況的變化．另一種方法是系統升級，這會影響現有應用的正常運行．並且當升級涉及不兼容的硬體或系統軟體有了重大修改而要相應地修改已開發的應用軟體時，升級的代價就十分昂貴而常常使得升級的方法不可行．分布式資料庫系統能方便地把一個新的結點納入系統，不影響現有系統的結構和系統的正常運行，提供了逐漸擴展系統能力的較好途徑，有時甚至是唯一的途徑。
①資料庫系統與應用 趙致格編著 清華大學出版社p. 260
②資料庫原理及應用 張晉連 編著 電子工業出版社P.13

⑤ 分布式資料庫的分布式資料庫相對傳統集中式資料庫的優點

大數據時代，面對日益增長的海量數據，傳統的集中式資料庫的弊端日益顯現，分布式資料庫相對傳統的集中式資料庫有如下優點。
● 更高的數據訪問速度：分布式資料庫為了保證數據的高可靠性，往往採用備份的策略實現容錯，所以，在讀取數據的時候，客戶端可以並發地從多個
備份伺服器同時讀取，從而提高了數據訪問速度。
● 更強的可擴展性：分布式資料庫可以通過增添存儲節點來實現存儲容量的線性擴展，而集中式資料庫的可擴展性十分有限。
● 更高的並發訪問量：分布式資料庫由於採用多台主機組成存儲集群，所以相對集中式資料庫，它可以提供更高的用戶並發訪問量。

⑥ 什麼是分布式資料庫

精確的分布式資料庫定義：分布式資料庫是由一組數據組成的，這組數據分布在計算機網路中的不同的計算機上，網路中的每個節點具有獨立處理的能力(稱為場地自治)，可以執行局部應用。同時，每個節點也能通過網路通信子系統執行全局應用。與之前的定義相比，更注重場地自治性以及自治場地之間的協作性。

分布式資料庫系統：一個粗略的定義是“分布式資料庫由一組數據組成，這些數據物理上分布在計算機網路的不同節點上(亦稱場地)上，邏輯上是屬於同一個系統。” 這里強調兩點：

(1)分布性：資料庫中的數據不是存儲在同一場地，更確切的說，不存儲在同一計算機的存儲設備上，這就可以和集中式資料庫相互區別。

(2)邏輯整體性：這些數據邏輯上是互相聯系的，是一個整體(邏輯上如同集中資料庫)。

⑦ 國產分布式資料庫到底怎麼樣

分布式是趨勢。
推薦一款有幸用過，使用效果很好的國產分布式資料庫——思極有容資料庫。
趨勢價值分析
1）分布式是趨勢，但是技術門檻高，對研發，運維的水平要求高。；
2）思極有容資料庫作為分布式解決方案對應用透明，研發人員精力集中在業務實現，而不是被分庫分表耗費過多精力，從而提高效率，這是一個很有價值和意義的事情。
如果和傳統國產資料庫廠家，例如達夢、人大、神通等相比，思極有容資料庫採用原生分布式架構，在集群擴展性和大規模部署後集群性能方面有較大優勢；同時思極有容資料庫 完全兼容和繼承MySQL生態，非常的易用易適配，可以無縫銜接大量第三方數據處理組件，有巨大的生態優勢。
和開源資料庫MySQL/PostgreSQL相比，思極有容資料庫 具備強大的擴展能力和准線性的性能提升優勢，在數據存儲容量、事務吞吐性能、資料庫原生高可用方面具備碾壓優勢。
和新興分布式資料庫廠家，例如阿里DRDS、騰訊TDSQL等相比，思極有容資料庫具備更加完備的SQL語法支持，具備更加強大的事務吞吐性能，對應用適配更加友好。

⑧ 什麼叫分布式資料庫，有什麼優點和缺點

1.分布式資料庫是資料庫的一種，是資料庫技術和網路技術的結合產物。

2.各有優點和缺點.分布式資料庫分為邏輯上分部物理上分布及邏輯上分布物理上集中兩種。

是的,分布式數據文件便於資料庫的管理維護。

⑨ 分布式資料庫與資料庫集群的區別到底是什麼哪位高手幫忙解惑下~~~~~~~~~~跪求

（1）另外一位博主的觀點（http://blog.csdn.net/bluishglc/article/details/5483162）

博主有對他的表述有作一點修改補充，方便各位猿友明了他的意思。

簡單說，分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。

例如：

如果一個任務由10個子任務組成，每個子任務單獨執行需1小時，則在一台伺服器上執行改任務需10小時。

採用分布式方案，提供10台伺服器，每台伺服器只負責處理一個子任務，不考慮子任務間的依賴關系，執行完這個任務只需一個小時。(這種工作模式的一個典型代表就是Hadoop的Map/Rece分布式計算模型）

而採用集群方案，同樣提供10台伺服器，每台伺服器都能獨立處理這個任務。假設有10個任務同時到達，10個伺服器將同時工作，10小後，10個任務同時完成，這樣，整身來看，還是平均1小時完成一個任務！（注意這里的任務和子任務的區別）

（2）知乎（https://www.hu.com/question/20004877）

這個猿友描述得很簡單明了：

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

另外一位猿友從另外一個角度去表述：

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

這位猿友的描述也很簡潔，但是比較抽象：

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

（3）網路（http://ke..com/view/4804677.htm、http://ke..com/view/3022776.htm）

集群：

集群是一組相互獨立的、通過高速網路互聯的計算機，它們構成了一個組，並以單一系統的模式加以管理。一個客戶與集群相互作用時，集群像是一個獨立的伺服器。集群配置是用於提高可用性和可縮放性。

分布式：

一種基於網路的計算機處理技術，與集中式相對應。由於個人計算機的性能得到極大的提高及其使用的普及，使處理能力分布到網路上的所有計算機成為可能。分布式計算是和集中式計算相對立的概念，分布式計算的數據可以分布在很大區域。

看完這些是不是有種似懂非懂的感覺？博主也是一樣！所以我們接下來繼續了解。

上面博主有說過自己有接觸過分布式服務框架Dubbo，那麼我們看看它為什麼說自己是分布式服務架構？（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%83%8C%E6%99%AF）

分布式服務架構

當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
此時，用於提高業務復用及整合的 分布式服務框架(RPC) 是關鍵。

偶然之間，有發現據說「Git就是分布式版本控制系統」，為什麼它是分布式的呢？

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://bbo.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://bbo.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，如果要修改，請配置<bbo:parameter key="hash.arguments" value="0,1" />
預設用160份虛擬節點，如果要修改，請配置<bbo:parameter key="hash.nodes" value="320" />

還有比較好奇它們是怎麼通信的？

像早期版本的Elasticsearch的話，自動發現節點機制，ES是一個基於p2p的系統，它先通過廣播尋找存在的節點，再通過多播協議來進行節點之間的通信，同時也支持點對點的交互。

而Dubbo是有個注冊中心，它支持多個注冊中心，但是推薦使用ZooKeeper。關於ZooKeeper可以自行了解，很多集群相關的框架都有使用到它。當然像Elasticsearch是自己有相應的機制實現的。