SQL Server負載均衡；數(shù)據(jù)庫集群

前言?
Internet的規(guī)模每一百天就會增長一倍，客戶希望獲得7天×24小時的不間斷可用性及較快的系統(tǒng)反應時間，而不愿屢次看到某個站點“Server Too Busy”及頻繁的系統(tǒng)故障。?
隨 著業(yè)務量的提高,以及訪問量和數(shù)據(jù)流量的快速增長，網(wǎng)絡各個核心部分的處理性能和計算強度也相應增大，使得單一設備根本無法承擔。在此情況下，如果扔掉現(xiàn) 有設備去做大量的硬件升級，必將造成現(xiàn)有資源的浪費，而且下一次業(yè)務量的提升，又將導致再一次硬件升級的高額成本投入。于是，負載均衡機制應運而生。?

ORACLE的“RAC”啟示?
對于負載均衡，筆者經(jīng)常接觸的當屬Oracle的負載均衡機制。下面，我們先簡單了解Oracle的負載均衡的實現(xiàn)方案。?
Real Application Clusters是并行服務器(8i及以前版本稱作Oracle Parallel Server，OPS)，用來在集群環(huán)境下實現(xiàn)多機共享數(shù)據(jù)庫，以保證應用的高可用性，同時可以自動實現(xiàn)并行處理及均分負載，還能實現(xiàn)數(shù)據(jù)庫在故障時的排 錯和無斷點恢復。它可以自動進行負載平衡、故障修復和規(guī)劃停機時間，以支持高可用性應用程序。若并行服務器中某節(jié)點失效，透明的應用程序容錯能夠把用戶自 動轉(zhuǎn)接到另一節(jié)點上繼續(xù)運行，應用程序在用戶沒有察覺的情況下繼續(xù)執(zhí)行。這使周期性和非周期性發(fā)生故障的系統(tǒng)增大了連續(xù)可用性。進程的失效可以完全透明地 轉(zhuǎn)移到另一節(jié)點上去，通過適當?shù)嘏渲?#xff0c;可以指定所有查詢都在客戶端進行緩存，這樣它們便可以在轉(zhuǎn)移后的節(jié)點上重新設置。那么在SQL Server平臺上是否也可以實現(xiàn)類似的效果？?

1、集群的分類?
一 般來講，集群軟件根據(jù)側(cè)重的方向和試圖解決的問題，分為三大類：高性能集群（High performance cluster，HPC）、負載均衡集群（Load balance cluster， LBC），高可用性集群（High availability cluster，HAC）。?
高 性能集群（High performance cluster，HPC），它是利用一個集群中的多臺機器共同完成同一件任務，使得完成任務的速度和可靠性都遠遠高于單機運行的效果。彌補了單機性能上的 不足。該集群在天氣預報、環(huán)境監(jiān)控等數(shù)據(jù)量大，計算復雜的環(huán)境中應用比較多；?
負 載均衡集群（Load balance cluster， LBC），它是利用一個集群中的多臺單機，完成許多并行的小的工作。一般情況下，如果一個應用使用的人多了，那么用戶請求的響應時間就會增大，機器的性能 也會受到影響，如果使用負載均衡集群，那么集群中任意一臺機器都能響應用戶的請求，這樣集群就會在用戶發(fā)出服務請求之后，選擇當時負載最小，能夠提供最好 的服務的這臺機器來接受請求并相應，這樣就可用用集群來增加系統(tǒng)的可用性和穩(wěn)定性。這類集群在網(wǎng)站中使用較多；?
高 可用性集群（High availability cluster，HAC），它是利用集群中系統(tǒng) 的冗余，當系統(tǒng)中某臺機器發(fā)生損壞的時候，其他后備的機器可以迅速的接替它來啟動服務，等待故障機的維修和返回。最大限度的保證集群中服務的可用性。這類 系統(tǒng)一般在銀行，電信服務這類對系統(tǒng)可靠性有高的要求的領域有著廣泛的應用。?

2、Microsoft Cluster Server(MSCS)相對于單點來說Microsoft Cluster Server(MSCS)是一個可以提升可用性的技術，不可以負載均衡的，Microsoft稱之為故障轉(zhuǎn)移集群。(屬于高可用集群共享磁盤架構)?

從硬件連接上看，很像Oracle的RAC，兩個節(jié)點，通過網(wǎng)絡連接，共享磁盤；事實上SQL Server數(shù)據(jù)庫只運行在一個節(jié)點上，當出現(xiàn)故障時，另一個節(jié)點只是作為這個節(jié)點的備份；?
因為始終只有一個節(jié)點在運行，在性能上也得不到提升,系統(tǒng)也就不具備擴展的能力。當現(xiàn)有的機器不能滿足應用的負載時只能更換更高配置的機器。?
升級到綜合性能更強大的硬件，帶來的問題是硬件的浪費，然而，單節(jié)點體系結(jié)構最終會達到一個瓶頸并無法實現(xiàn)進一步的有效擴展。具體表現(xiàn)為逐漸縮小的回報率或者價格驚人的昂貴硬件設備，系統(tǒng)得不到可持續(xù)的擴展。?

4、復制、訂閱?
我 們知道，SQL Server 提供了復制技術（Replication），可以有多個只讀服務器供查詢用，這個技術可以有效緩解查詢的壓力。我們知道，復制、訂閱是一個讀寫分離的技 術，數(shù)據(jù)先寫到中心數(shù)據(jù)庫上，寫成功即返回給應用程序；通過復制將數(shù)據(jù)復制到只讀的服務器，查詢的時候從只讀服務器查。?

這就意味著訂閱端的數(shù)據(jù)和中心數(shù)據(jù)庫的數(shù)據(jù)不同步，是個異步的過程，所以數(shù)據(jù)滯后嚴重，數(shù)據(jù)同步的實時性得不到保障，中心數(shù)據(jù)庫在正常的壓力下10秒左右。當訪問負荷很高或者中心數(shù)據(jù)庫在整理數(shù)據(jù)時，將出現(xiàn)大量DML操作時延遲時間比較長或者出現(xiàn)堵塞的情況；?
某些修改操作需要重新建立復制關系并初始化，這期間需要停止數(shù)據(jù)庫的讀取服務，規(guī)模越大的應用停止的時間越長，嚴重影響了數(shù)據(jù)庫的可用性。 另外中心數(shù)據(jù)庫所采用的結(jié)構還是MSCS，只是提供了一種故障轉(zhuǎn)移的機制，當有一個節(jié)點出現(xiàn)問題后把負載轉(zhuǎn)移到另一個節(jié)點上；?
結(jié) 論：從上面可以看出，在MS-SQL Server 平臺上沒有提供類似Oracle RAC的技術，實現(xiàn)不了負載均衡。數(shù)據(jù)庫的高并發(fā)及橫向擴展是用戶經(jīng)常遇到的問題，所以好多SQL Server用戶遇到這樣的困惑時就移植到Oracle平臺上，采用RAC來解決。這將是一個即費財力又費物力、人力，同時還要面臨很大風險的一個艱難過 程。?
所以說在MS-SQL Server平臺上實現(xiàn)像Oracle RAC一樣高性能、高可用性和方便擴展的集群解就成廣大SQL Server用戶期待的一個焦點，就目前來說，這類技術似乎只能在在一些專業(yè)研究第三方數(shù)據(jù)庫集群的公司看到。?

數(shù)據(jù)庫負載均衡集群的實現(xiàn)?
1、實現(xiàn)原理?
實 現(xiàn)數(shù)據(jù)庫的負載均衡技術，首先要有一個可以控制連接數(shù)據(jù)庫的控制端。在這里，它截斷了數(shù)據(jù)庫和程序的直接連接，由所有的程序來訪問這個中間層，然后再由中 間層來訪問數(shù)據(jù)庫。這樣，我們就可以具體控制訪問某個數(shù)據(jù)庫了，然后還可以根據(jù)數(shù)據(jù)庫的當前負載采取有效的均衡策略，來調(diào)整每次連接到哪個數(shù)據(jù)庫。好處在 兩個方面:首先，它成功地將數(shù)據(jù)庫放到了內(nèi)網(wǎng)之中，更好地保護了數(shù)據(jù)庫的安全性。如果數(shù)據(jù)庫也在公網(wǎng)上，1433端口是很容易被***的，所以要保護數(shù)據(jù)庫 與之的連接，就用到了中間層。它可以將數(shù)據(jù)庫更加好地保護在內(nèi)網(wǎng)。其次，對應用來說完全透明，集群暴露出來的就是一個IP ，連接數(shù)據(jù)庫的所有連接都可以控制，更方便DBA對數(shù)據(jù)的管理，看哪些連接更耗費數(shù)據(jù)庫資源，以便更好地優(yōu)化代碼。?
但 是，也有兩點要注意:第一，必須要做成Windows的服務程序。Windows發(fā)展到今天，如果以一個集成的大系統(tǒng)來講，做成服務程序更加穩(wěn)定，也更加 安全，這樣做即使用戶不登錄機器，也可以使用。第二，必須要使用多個中間層。從中間層的作用可以看出，它承接了數(shù)據(jù)庫的所有連接，所以，一旦出了問題，就 會導致整個系統(tǒng)癱瘓。所以做多個中間層是必要的，這樣，如果一個壞了可以登錄到另一個。?

2、實現(xiàn)多據(jù)庫數(shù)據(jù)同步?
前 端連接數(shù)據(jù)庫起均衡作用的有了，下一步的工作是設置構建數(shù)據(jù)庫集群。對于負載均衡，最重要的就是所有服務器的數(shù)據(jù)都是實時同步的。這是一個集群所必需的， 因為，如果數(shù)不據(jù)實時、不同步，那么用戶從一臺服務器讀出的數(shù)據(jù)，就有別于從另一臺服務器讀出的數(shù)據(jù)，這是不能允許的。所以必須實現(xiàn)數(shù)據(jù)庫的數(shù)據(jù)同步。這 樣，在查詢的時候就可以有多個資源，實現(xiàn)均衡。?
Moebius 集群采用將核心程序駐留在每個機器的數(shù)據(jù)庫中的辦法，這個核心程序稱為Moebius 中間件，主要作用是監(jiān)測數(shù)據(jù)庫內(nèi)數(shù)據(jù)的變化并將變化的數(shù)據(jù)同步到其他數(shù)據(jù)庫中。數(shù)據(jù)同步完成后客戶端才會得到響應，同步過程是并發(fā)完成的，所以同步到多個 數(shù)據(jù)庫和同步到一個數(shù)據(jù)庫的時間基本相等；另外同步的過程是在事務的環(huán)境下完成的，保證了多份數(shù)據(jù)在任何時刻數(shù)據(jù)的一致性。?
正因為Moebius 中間件宿主在數(shù)據(jù)庫中的創(chuàng)新，讓中間件不但能知道數(shù)據(jù)的變化，而且知道引起數(shù)據(jù)變化的SQL語句，根據(jù)SQL語句的類型智能的采取不同的數(shù)據(jù)同步的策略以保證數(shù)據(jù)同步成本的最小化。?

數(shù)據(jù)條數(shù)很少，數(shù)據(jù)內(nèi)容也不大，則直接同步數(shù)據(jù)?
數(shù)據(jù)條數(shù)很少，但是里面包含大數(shù)據(jù)類型，比如文本，二進制數(shù)據(jù)等，則先對數(shù)據(jù)進行壓縮然后再同步，從而減少網(wǎng)絡帶寬的占用和傳輸所用的時間。?
數(shù)據(jù)條數(shù)很多，此時中間件會拿到造成數(shù)據(jù)變化的SQL語句， 然后對SQL語句進行解析，分析其執(zhí)行計劃和執(zhí)行成本，并選擇是同步數(shù)據(jù)還是同步SQL語句到其他的數(shù)據(jù)庫中。此種情況應用在對表結(jié)構進行調(diào)整或者批量更改數(shù)據(jù)的時候非常有用。?

Moebius中間件同步策略?
數(shù)據(jù)壓縮：?
如果需要同步的數(shù)據(jù)中包含文本、二進制等大數(shù)據(jù)類型， 則先對數(shù)據(jù)進行壓縮然后再同步，從而減少對網(wǎng)絡帶寬的消耗和數(shù)據(jù)在傳輸過程中所用的時間。尤其對于網(wǎng)絡帶寬資源非常稀缺的場景。 通過fire_compression_bytes參數(shù)進行閥值控制。?
批量執(zhí)行重復性數(shù)據(jù)：?
如果需要同步的數(shù)據(jù)中包含重復性的數(shù)據(jù)，則中間件會把重復性的數(shù)據(jù)合并到一個同步命令中只執(zhí)行一次，從而減少執(zhí)行的次數(shù)。?
例 如：執(zhí)行語句 UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE LastLoginDate < '2008-08-08' 共修改了600條數(shù)據(jù)，這600條數(shù)據(jù)的DeleteFlag列具有相同的值，中間件會把這些相同的值合并到一個同步命令中去，同步的SQL語句 為：UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID IN(1, 3, 4, 5, 7, 10, 13, 15, ......, 895, 897, 899, 1000)。而不是逐條的去同步：?
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 1?
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 3?
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 4?
.?
.?
.?
.?
.?
.?
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 899?
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 1000?
該策略對數(shù)據(jù)進行批量更新、批量刪除的場景下非常有用。 通過rows_in_command參數(shù)進行閥值控制。?
升級數(shù)據(jù)庫鎖（鎖優(yōu)化器）?
如 果更新的數(shù)據(jù)量非常大，SQL Server本身會對鎖進行升級，將大量較細粒度的鎖（例如行）轉(zhuǎn)換為少量較粗粒度的鎖（例如表）從而減少系統(tǒng)開銷。中間件在同步之前先檢查當前SQL Server的鎖的粒度，如果鎖已經(jīng)升級，則中間件先對目標數(shù)據(jù)庫直接進行鎖升級然后再同步數(shù)據(jù)。從而避免了目標數(shù)據(jù)庫鎖升級的過程。通過 fire_lock_optimizer_rows 參數(shù)進行閥值控制。?

同步SQL語句（同步優(yōu)化器）?
如 果更新的數(shù)據(jù)量非常大，超過了設定的閥值，同步大量的數(shù)據(jù)勢必會消耗大量的網(wǎng)絡帶寬并且延長同步的時間，甚至會造成網(wǎng)絡擁堵。這時候中間件首先獲取導致數(shù) 據(jù)變化的SQL語句，分析該SQL語句的類型以及執(zhí)行成本，并選擇是把變化的數(shù)據(jù)同步過去還是把導致數(shù)據(jù)變化的SQL語句同步過去。該策略在對表結(jié)構進行 調(diào)整或批量更改數(shù)據(jù)的時候非常有用，大量的減少網(wǎng)絡帶寬的消耗，降低同步時間。通過fire_sync_optimizer_rows 參數(shù)進行閥值控制。?

并發(fā)執(zhí)行SQL語句?
即 使使用了同步SQL語句策略，總的執(zhí)行時間也相當于執(zhí)行兩次SQL語句的時間。如果這個時間還是不能接受。可以通過中間件提供的系統(tǒng)存儲過程 usp_MBS_ParallelExecute在集群中的各個節(jié)點數(shù)據(jù)庫中并發(fā)執(zhí)行SQL語句，使執(zhí)行時間降低到相當于在單機數(shù)據(jù)庫中執(zhí)行一次的時間。 但是要注意并不是所有的語句都適合并發(fā)執(zhí)行，具體請參見usp_MBS_ParallelExecute。?

4、透明性?
中間件宿主在SQL Server數(shù)據(jù)庫中，這是Moebius 的一個創(chuàng)新，主要是確保原有的數(shù)據(jù)庫架構移植到集群架構上簡單方便，避免對系統(tǒng)進行較大的改造。?
對開發(fā)透明：?
中間件是在數(shù)據(jù)庫內(nèi)部工作的，不改變SQL Server原來的應用特性，開發(fā)人員面對的還是熟悉的SQL Server數(shù)據(jù)庫、SQL語句以及開發(fā)/調(diào)試工具。不需要改變原有的習慣,不需要學習新的工具。?
許多關鍵的數(shù)據(jù)庫技術比如事務、連接池、鎖、數(shù)據(jù)存儲、安全等還是依靠SQL Server數(shù)據(jù)庫來完成，對客戶來說，無論是研發(fā)成本還是實施風險都降到最低。?
對管理透明：?
對于管理人員來說，仍然可以使用SQL Server提供的管理工具來管理數(shù)據(jù)庫，可以把集群看成一個數(shù)據(jù)庫來管理，系統(tǒng)進行了封裝，感覺和使用原來的一個數(shù)據(jù)庫時候一樣，易用性非常好。?
對應用透明：?
對于應用程序的連接，用戶只需要在應用程序連接組件中進行配置，將應用程序與數(shù)據(jù)庫集群連接即可，對您的應用程序及業(yè)務沒有絲毫影響。

轉(zhuǎn)載于:https://blog.51cto.com/tianshili/1640091

總結(jié)

以上是生活随笔為你收集整理的Moebius中间件的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。