集群術(shù)語須知

• 服務(wù)硬件：指提供計算服務(wù)的硬件，比如 PC 機、PC 服務(wù)器。
• 服務(wù)實體：服務(wù)實體通常指服務(wù)軟體和服務(wù)硬體。
• 節(jié)點（NODE）：運行 Heartbeat 進程的一個獨立主機稱為節(jié)點，節(jié)點是 HA 的核心組成部分，每個節(jié)點上運行著操作系統(tǒng)和Heartbeat 軟件服務(wù)。
• 資源（RESOURCE）：資源是一個節(jié)點可以控制的實體，當(dāng)節(jié)點發(fā)生故障時，這些資源能夠被其他節(jié)點接管。如： 磁盤分區(qū)、文件系統(tǒng)、IP 地址、應(yīng)用程序服務(wù)、共享存儲。
• 事件（EVENT）：事件也就是集群中可能發(fā)生的事情，例如節(jié)點系統(tǒng)故障、網(wǎng)絡(luò)連通故障、網(wǎng)卡故障和應(yīng)用程序故障等。這些事件都會導(dǎo)致節(jié)點的資源發(fā)生轉(zhuǎn)移，HA 的測試也是基于這些事件進行的。

什么是集群

集群（cluster）就是一組計算機，它們作為一個整體向用戶提供一組網(wǎng)絡(luò)資源，這些單個的計算機系統(tǒng)就是集群的節(jié)點（node）。集群提供了以下關(guān)鍵的特性。

1. 可擴展性。集群的性能不限于單一的服務(wù)實體，新的服務(wù)實體可以動態(tài)的加入到集群，從而增強集群的性能。
2. 高可用性。集群通過服務(wù)實體冗余使客戶端免于輕易遭遇到“out of service”警告。當(dāng)一臺節(jié)點服務(wù)器發(fā)生故障的時候，這臺服務(wù)器上所運行的應(yīng)用程序?qū)⒃诹硪还?jié)點服務(wù)器上被自動接管。消除單點故障對于增強數(shù)據(jù)可用性、可達性和可靠性是非常重要的。
3. 負(fù)載均衡。負(fù)載均衡能把任務(wù)比較均勻的分布到集群環(huán)境下的計算和網(wǎng)絡(luò)資源，以便提高數(shù)據(jù)吞吐量。
4. 錯誤恢復(fù)。如果集群中的某一臺服務(wù)器由于故障或者維護需要而無法使用，資源和應(yīng)用程序?qū)⑥D(zhuǎn)移到可用的集群節(jié)點上。這種由于某個節(jié)點中的資源不能工作，另一個可用節(jié)點中的資源能夠透明的接管并繼續(xù)完成任務(wù)的過程叫做錯誤恢復(fù)。

分布式與集群的聯(lián)系與區(qū)別如下：

1. 分布式是指將不同的業(yè)務(wù)分布在不同的地方。
2. 而集群指的是將幾臺服務(wù)器集中在一起，實現(xiàn)同一業(yè)務(wù)。
3. 分布式的每一個節(jié)點，都可以做集群，而集群并不一定就是分布式的。而分布式，從狹義上理解，也與集群差不多，但是它的組織比較松散，不像集群，有一定組織性，一臺服務(wù)器宕了，其他的服務(wù)器可以頂上來。分布式的每一個節(jié)點，都完成不同的業(yè)務(wù)，一個節(jié)點宕了，這個業(yè)務(wù)就不可訪問了。

集群主要分成三大類：

1. HA：高可用集群（High Availability Cluster）。
2. LBC：負(fù)載均衡集群/負(fù)載均衡系統(tǒng)（Load Balance Cluster）
3. HPC：科學(xué)計算集群（High Performance Computing Cluster）/高性能計算（High Performance Computing）集群。

為什么搭建數(shù)據(jù)庫集群

隨著經(jīng)濟的高速發(fā)展，企業(yè)規(guī)模的迅猛擴張，企業(yè)用戶的數(shù)量、數(shù)據(jù)量的爆炸式增長，對數(shù)據(jù)庫提出了嚴(yán)峻的考驗。對于所有的數(shù)據(jù)庫而言，除了記錄正確的處理結(jié)果之外，還面臨著以下幾方面的挑戰(zhàn)。

• 如何提高處理速度，實現(xiàn)數(shù)據(jù)庫的均衡負(fù)載。
• 如何保證數(shù)據(jù)庫的可用性、數(shù)據(jù)安全性、以及如何實現(xiàn)數(shù)據(jù)集群可擴性。
• 怎么綜合解決這些問題成為眾多企業(yè)關(guān)注的焦點。

在數(shù)據(jù)庫上，組建集群也是同樣的道理，主要有以下幾個原因：

1. 伴隨著企業(yè)的成長，業(yè)務(wù)量提高，數(shù)據(jù)庫的訪問量和數(shù)據(jù)量快速增長，其處理能力和計算速度也相應(yīng)增大，使得單一的設(shè)備根本無法承擔(dān)。
2. 在以上情況下，若扔掉現(xiàn)有設(shè)備，做大量的硬件升級，勢必造成現(xiàn)有資源的浪費，而且下一次業(yè)務(wù)量提升時，又將面臨再一次硬件升級的高額投入。于是，人們希望通過幾個中小型服務(wù)器組建集群，實現(xiàn)數(shù)據(jù)庫的負(fù)載均衡及持續(xù)擴展；在需要更高數(shù)據(jù)庫處理速度時，只要簡單的增加數(shù)據(jù)庫服務(wù)器就可以得到擴展。
3. 數(shù)據(jù)庫作為信息系統(tǒng)的核心，起著非常重要的作用，單一設(shè)備根本無法保證系統(tǒng)的下持續(xù)運行，若發(fā)生系統(tǒng)故障，將嚴(yán)重影響系統(tǒng)的正常運行，甚至帶來巨大的經(jīng)濟損失。于是，人們希望通過組建數(shù)據(jù)庫集群，實現(xiàn)數(shù)據(jù)庫的高可用，當(dāng)某節(jié)點發(fā)生故障時，系統(tǒng)會自動檢測并轉(zhuǎn)移故障節(jié)點的應(yīng)用，保證數(shù)據(jù)庫的持續(xù)工作。
4. 企業(yè)的數(shù)據(jù)庫保存著企業(yè)的重要信息，一些核心數(shù)據(jù)甚至關(guān)系著企業(yè)的命脈，單一設(shè)備根本無法保證數(shù)據(jù)庫的安全性，一旦發(fā)生丟失，很難再找回來。于是，人們希望通過組建數(shù)據(jù)庫集群，實現(xiàn)數(shù)據(jù)集的冗余，通過備份數(shù)據(jù)來保證安全性。

數(shù)據(jù)庫集群的分類

數(shù)據(jù)庫集群技術(shù)是將多臺服務(wù)器聯(lián)合起來組成集群來實現(xiàn)綜合性能優(yōu)于單個大型服務(wù)器的技術(shù)，這種技術(shù)不但能滿足應(yīng)用的需要，而且大幅度的節(jié)約了投資成本。數(shù)據(jù)庫集群技術(shù)分屬兩類體系：基于數(shù)據(jù)庫引擎的集群技術(shù)和基于數(shù)據(jù)庫網(wǎng)關(guān)（中間件）的集群技術(shù)。在數(shù)據(jù)庫集群產(chǎn)品方面，其中主要包括基于數(shù)據(jù)庫引擎的集群技術(shù)的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE，以及基于數(shù)據(jù)庫網(wǎng)關(guān)（中間件）的集群技術(shù)的 ICX-UDS 等產(chǎn)品。

一般來講，數(shù)據(jù)庫集群軟件側(cè)重的方向和試圖解決的問題劃分為三大類：

• 負(fù)載均衡集群（LOAD BALANCE CLUSTER，LBC）側(cè)重于數(shù)據(jù)庫的橫向擴展，提升數(shù)據(jù)庫的性能。
• 高可用性集群（HIGH AVAILABILITY CLUSTER，HAC）側(cè)重保證數(shù)據(jù)庫應(yīng)用持續(xù)不斷。大部分的數(shù)據(jù)庫集群側(cè)重與此。
• 高安全性集群（HIGH SECURITY CLUSTER，HSC）側(cè)重于容災(zāi)。

只有 ORACLE RAC 能實現(xiàn)以上三方面

可擴展的分布式數(shù)據(jù)庫架構(gòu)

ORACLE RAC

其架構(gòu)的最大特點是共享存儲架構(gòu)（SHARED-STORAGE），整個 RAC 集群是建立在一個共享的存儲設(shè)備之上的，節(jié)點之間采用高速網(wǎng)絡(luò)互聯(lián)。OracleRAC 提供了非常好的高可用特性，比如負(fù)載均衡和應(yīng)用透明切塊（TAF），其最大的優(yōu)勢在于對應(yīng)用完全透明，應(yīng)用無需修改便可切換到RAC 集群。但是RAC 的可擴展能力有限，首先因為整個集群都依賴于底層的共享存儲，所以共享存儲的 I/O 能力和可用性決定了整個集群的可以提供的能力，對于 I/O 密集型的應(yīng)用，這樣的機制決定后續(xù)擴容只能是 Scale up（向上擴展）類型，對于硬件成本、開發(fā)人員的要求、維護成本都相對比較高。Oracle顯然也意識到了這個問題，在 Oracle 的 MAA（Maximum Availability Architecture）架構(gòu)中，采用 ASM 來整合多個存儲設(shè)備的能力，使得 RAC 底層的共享存儲設(shè)備具備線性擴展的能力，整個集群不再依賴于大型存儲的處理能力和可用性。

RAC 的另外一個問題是，隨著節(jié)點數(shù)的不斷增加，節(jié)點間通信的成本也會隨之增加，當(dāng)?shù)侥硞€限度時，增加節(jié)點可能不會再帶來性能上的提高，甚至可能造成性能下降。這個問題的主要原因是 Oracle RAC 對應(yīng)用透明，應(yīng)用可以連接集群中的任意節(jié)點進行處理，當(dāng)不同節(jié)點上的應(yīng)用爭用資源時，RAC 節(jié)點間的通信開銷會嚴(yán)重影響集群的處理能力。所以對于使用 ORACLE RAC 有以下兩個建議：

• 節(jié)點間通信使用高速互聯(lián)網(wǎng)絡(luò)；
• 盡可能將不同的應(yīng)用分布在不同的節(jié)點上。

基于這個原因，Oracle RAC 通常在 DSS 環(huán)境（決策支持系統(tǒng)Decision Support System ，簡稱DSS)中可以做到很好的擴展性，因為 DSS 環(huán)境很容易將不同的任務(wù)分布在不同計算節(jié)點上，而對于 OLTP 應(yīng)用（On-Line Transaction Processing聯(lián)機事務(wù)處理系統(tǒng)），Oracle RAC 更多情況下用來提高可用性，而不是為了提高擴展性。

MYSQL CLUSTER

MySQL cluster 和 Oracle RAC 完全不同，它采用 無共享架構(gòu)Shared nothing（shared nothing architecture）。整個集群由管理節(jié)點(NDB_MGMD)，處理節(jié)點(MYSQLD)和存儲節(jié)點(ndbd)組 成，不存在一個共享的存儲設(shè)備。MySQL cluster 主要利用了 NDB 存儲引擎來實現(xiàn)，NDB 存儲引擎是一個內(nèi)存式存儲引擎，要求數(shù)據(jù)必須全部加載到內(nèi)存之中。數(shù)據(jù)被自動分布在集群中的不同存 儲節(jié)點上，每個存儲節(jié)點只保存完整數(shù)據(jù)的一個分片(fragment)。同時，用戶可以設(shè)置同一份數(shù)據(jù)保存在多個不同的存儲節(jié)點上，以保證單點故障不會造 成數(shù)據(jù)丟失。MySQL cluster 主要由 3 各部分組成：

• SQL 服務(wù)器節(jié)點
• NDB 數(shù)據(jù)存儲節(jié)點
• 監(jiān)控和管理節(jié)點

這樣的分層也是與 MySQL 本身把 SQL 處理和存儲分開的架構(gòu)相關(guān)系的。MySQL cluster 的優(yōu)點在于其是一個分布式的數(shù)據(jù)庫集群，處理節(jié)點和存儲節(jié)點都可以線性增加，整個集群沒有單點故障，可用性和擴展性都可以做到很高，更適合 OLTP 應(yīng)用。但是它的問題在于：

• NDB（“NDB” 是一種“內(nèi)存中”的存儲引擎，它具有可用性高和數(shù)據(jù)一致性好的特點。） 存儲引擎必須要求數(shù)據(jù)全部加載到內(nèi)存之中，限制比較大，但是目前 NDB 新版本對此做了改進，允許只在內(nèi)存中加 載索引數(shù)據(jù)，數(shù)據(jù)可以保存在磁盤上。
• 目前的 MySQL cluster 的性能還不理想，因為數(shù)據(jù)是按照主鍵 hash 分布到不同的存儲節(jié)點上，如果應(yīng)用不是通過主鍵去獲取數(shù)據(jù)的話，必須在所有的存儲節(jié)點上掃描， 返回結(jié)果到處理節(jié)點上去處理。而且，寫操作需要同時寫多份數(shù)據(jù)到不同的存儲節(jié)點上，對節(jié)點間的網(wǎng)絡(luò)要求很高。

雖然 MySQL cluster 目前性能還不理想，但是 share nothing 的架構(gòu)一定是未來的趨勢，Oracle 接手 MySQL之后，也在大力發(fā)展 MySQL cluster，我對 MySQL cluster 的前景抱有很大的期待。

分布式數(shù)據(jù)庫架構(gòu)

MySQL 5 之后才有了數(shù)據(jù)表分區(qū)功能（Sharding）， Sharding 不是一個某個特定數(shù)據(jù)庫軟件附屬的功能，而是在具體技術(shù)細節(jié)之上的抽象處理，是水平擴展(Scale Out，亦或橫向擴展、向外擴展)的解決方案，其主要目的是為突破單節(jié)點數(shù)據(jù)庫服務(wù)器的 I/O 能力限制，解決數(shù)據(jù)庫擴展性問題。比如 Oracle 的 RAC 是采用共享存儲機制，對于 I/O 密集型的應(yīng)用，瓶頸很容易落在存儲上，這樣的機制決定后續(xù)擴容只能是 Scale Up（向上擴展） 類型，對于硬件成本、開發(fā)人員的要求、維護成本都相對比較高。Sharding 基本上是針對開源數(shù)據(jù)庫的擴展性解決方案，很少有聽說商業(yè)數(shù)據(jù)庫進行 Sharding 的。目前業(yè)界的趨勢基本上是擁抱 Scale Out，逐漸從 Scale Up 中解放出來。

Sharding 架構(gòu)的優(yōu)勢在于，集群擴展能力很強，幾乎可以做到線性擴展，而且整個集群的可用性也很高，部分節(jié)點故障，不會影響其他節(jié)點提供服務(wù)。Sharding 原理簡單，容易實現(xiàn)，是一種非常好的解決數(shù)據(jù)庫擴展性的方案。Sharding 并不是數(shù)據(jù)庫擴展方案的銀彈，也有其不適合的場景，比如處理事務(wù)型的應(yīng)用它可能會造成應(yīng)用架構(gòu)復(fù)雜或者限制系統(tǒng)的功能，這也是它的缺陷所在。讀寫分離是架構(gòu)分布式系統(tǒng)的一個重要思想。不少系統(tǒng)整體處理能力并不能同業(yè)務(wù)的增長保持同步，因此勢必會帶來瓶頸，單純的升級硬件并不能一勞永逸。針對業(yè)務(wù)類型特點，需要從架構(gòu)模式進行一系列的調(diào)整，比如業(yè)務(wù)模塊的分割，數(shù)據(jù)庫的拆分等等。集中式和分布式是兩個對立的模式，不同行業(yè)的應(yīng)用特點也決定了架構(gòu)的思路。如互聯(lián)網(wǎng)行業(yè)中一些門戶站點，出于技術(shù)和成本等方面考慮，更多的采用開源的數(shù)據(jù)庫產(chǎn)品(如 MYSQL)，由于大部分是典型的讀多寫少的請求，因此為 MYSQL 及其復(fù)制技術(shù)大行其道提供了條件。而相對一些傳統(tǒng)密集交易型的行業(yè)，比如電信業(yè)、金融業(yè)等，考慮到單點處理能力和可靠性、穩(wěn)定性等問題，可能更多的采用商用數(shù)據(jù)庫，比如 DB2、ORACLE 等。就數(shù)據(jù)庫層面來講，大部分傳統(tǒng)行業(yè)核心庫采用集中式的架構(gòu)思路，采用高配的小型機做主機載體，因為數(shù)據(jù)庫本身和主機強大的處理能力，數(shù)據(jù)庫端一般能支撐業(yè)務(wù)的運轉(zhuǎn)，因此，Oracle 讀寫分離式的架構(gòu)相對MYSQL 來講，相對會少。讀寫分離架構(gòu)利用了數(shù)據(jù)庫的復(fù)制技術(shù)，將讀和 寫分布在不同的處理節(jié)點上，從而達到提高可用性和擴展性的目的。最通常的做法是利用 MySQL Replication 技術(shù)，Master DB 承擔(dān)寫操作，將數(shù)據(jù)變化復(fù)制到多臺 Slave DB上，并承擔(dān)讀的操作。這種架構(gòu)適合 read-intensive 類型的應(yīng)用，通過增加 Slave DB 的數(shù)量，讀的性能可以線性增長。為了避免 Master DB 的單點故障，集群一般都會采用兩臺 Master DB 做雙機熱備，所以整個集群的讀和寫的可用性都非常高。除了 MySQL，ORACLE 從 11G 開始提供 Active Standby 的功能，也具備了實現(xiàn)讀寫分離架構(gòu)的基礎(chǔ)。讀寫分離架構(gòu)的缺陷在于，不管是 Master 還是 Slave，每個節(jié)點都必須保存完整的數(shù)據(jù)，如 果在數(shù)據(jù)量很大的情況下，集群的擴展能力還是受限于單個節(jié)點的存儲能力，而且對于 Write-intensive 類型的應(yīng)用，讀寫分離架構(gòu)并不適合。 采用 Oracle 讀寫分離的思路，Writer DB 和 Reader DB 采用日志復(fù)制軟件實現(xiàn)實時同步； Writer DB 負(fù)責(zé)交易相關(guān)的實時查詢和事務(wù)處理，Reader DB 負(fù)責(zé)只讀接入，處理一些非實時的交易明細,報表類的匯總查詢等。同時，為了滿足高可用性和擴展性等要求，對讀寫端適當(dāng)做外延，比如 Writer DB 采用 HA 或者 RAC 的架構(gòu)模式，目前，除了數(shù)據(jù)庫廠商的 集群產(chǎn)品以外，解決數(shù)據(jù)庫擴展能力的方法主要有兩個：數(shù)據(jù)分片和讀寫分離。數(shù)據(jù)分片(Sharding)的原理就是將數(shù)據(jù)做水平切分，類似于 hash 分區(qū) 的原理，通過應(yīng)用架構(gòu)解決訪問路由和Reader DB 可以采用多套，通過負(fù)載均衡或者業(yè)務(wù)分離的方式，有效分擔(dān)讀庫的壓力。

對于 Shared-nothing 的數(shù)據(jù)庫架構(gòu)模式，核心的一個問題就是讀寫庫的實時同步；另外，雖然 Reader DB只負(fù)責(zé)業(yè)務(wù)查詢，但并不代表數(shù)據(jù)庫在功能上是只讀的。只讀是從應(yīng)用角度出發(fā)，為了保證數(shù)據(jù)一致和沖突考慮，因為查詢業(yè)務(wù)模塊可能需要涉及一些中間處理，如果需要在數(shù)據(jù)庫里面處理(取決與應(yīng)用需求和設(shè)計)，所以Reader DB 在功能上仍然需要可寫。下面談一下數(shù)據(jù)同步的技術(shù)選型問題：

能實現(xiàn)數(shù)據(jù)實時同步的技術(shù)很多，基于 OS 層(例如 VERITAS VVR)，基于存儲復(fù)制(中高端存儲大多都支持)，基于應(yīng)用分發(fā)或者基于數(shù)據(jù)庫層的技術(shù)。因為數(shù)據(jù)同步可能并不是單一的 DB 整庫同步，會涉及到業(yè)務(wù)數(shù)據(jù)選擇以及多源整合等問題，因此 OS 復(fù)制和存儲復(fù)制多數(shù)情況并不適合做讀寫分離的技術(shù)首選?；谌罩镜?Oracle 復(fù)制技術(shù)，Oracle 自身組件可以實現(xiàn)，同時也有成熟的商業(yè)軟件。選商業(yè)的獨立產(chǎn)品還是 Oracle 自身的組件功能，這取決于多方面的因素。比如團隊的相應(yīng)技術(shù)運維能力、項目投入成本、業(yè)務(wù)系統(tǒng)的負(fù)載程度等。

采用 Oracle 自身組件功能，無外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard)，對比來說，Stream 最靈活，但最不穩(wěn)定，11g Physical Standby 支持恢復(fù)與只讀并行，但由于并不是日志的邏輯應(yīng)用機制，在讀寫分離的場景中最為局限。如果技術(shù)團隊對相關(guān)技術(shù)掌握足夠充分，而選型方案的處理能力又能支撐數(shù)據(jù)同步的要求，采用 Oracle 自身的組件完全可行。選擇商業(yè)化的產(chǎn)品，更多出于穩(wěn)定性、處理能力等考慮。市面上成熟的 Oracle 復(fù)制軟件也無外乎幾種，無論是老牌的 Shareplex，還是本土 DSG 公司的 RealSync 和九橋公司的 DDS，或是 Oracle 新貴 Goldengate，都是可供選擇的目標(biāo)。隨著 GoldenGate 被 Oracle 收購和推廣，個人認(rèn)為 GoldenGate 在容災(zāi)、數(shù)據(jù)分發(fā)和同步方面將大行其道。當(dāng)然，架構(gòu)好一個可靠的分布式讀寫分離的系統(tǒng)，還需要應(yīng)用上做大量設(shè)計，不在本文討論范圍內(nèi)。