集群術語須知

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

什么是集群

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

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

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

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

集群主要分成三大類：

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

為什么搭建數據庫集群

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

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

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

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

數據庫集群的分類

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

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

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

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

可擴展的分布式數據庫架構

ORACLE RAC

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

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

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

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

MYSQL CLUSTER

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

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

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

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

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

分布式數據庫架構

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

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

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

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

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