數(shù)據(jù)庫集群應(yīng)用

時間：2023-02-11 00:15:01 | 來源：營銷百科

時間：2023-02-11 00:15:01 來源：營銷百科

數(shù)據(jù)庫集群應(yīng)用：一．基于實時數(shù)據(jù)同步技術(shù)

基于此技術(shù)構(gòu)造的數(shù)據(jù)庫集群是市場上的新興力量，它又具有兩類，分別是：

a.具有獨立網(wǎng)關(guān)

下面以DBTwin為例來說明其技術(shù)特點。

DBTwin采用了冗余設(shè)計原理，對于來自客戶端的請求，請求被分成兩類：查詢請求和數(shù)據(jù)更新請求。對于數(shù)據(jù)更新請求，集群內(nèi)部各節(jié)點之間保持?jǐn)?shù)據(jù)的實時同步一致；對于數(shù)據(jù)的查詢請求，則可以在集群各節(jié)點之間負(fù)載均衡執(zhí)行。它的特點是：

a) 負(fù)載均衡的單元是客戶端的每個獨立請求，這點除了Oracle RAC集群，是市場上獨有的。

b) 實時冗余一致的多份數(shù)據(jù)，從理論上講實現(xiàn)了數(shù)據(jù)的零丟失。

c) 由于可以做到數(shù)據(jù)零丟失，因此在系統(tǒng)發(fā)生任意故障條件下，可以做到系統(tǒng)的對外服務(wù)不停止。

d) 此系統(tǒng)使用了專用高速數(shù)據(jù)同步技術(shù)，根據(jù)測試，數(shù)據(jù)同步速度能SQL Server的鏡像相等。

e) 此系統(tǒng)的缺點是數(shù)據(jù)同步需要花費代價,節(jié)點數(shù)量受到限制，一般2到4個節(jié)點為宜。

f) 此系統(tǒng)從宏觀上提升了整個系統(tǒng)的性能。

b.將調(diào)度節(jié)點集成于數(shù)據(jù)庫引擎

下面以Moebius來說明其技術(shù)特點。

任何在數(shù)據(jù)庫和應(yīng)用程序之間引入的中間件都同時引入了單點故障點，如果中間件（網(wǎng)關(guān)）出現(xiàn)了故障，則數(shù)據(jù)庫集群就會形同虛設(shè)。因此Moebius在集群中的每個節(jié)點上都存在于嵌入于數(shù)據(jù)庫引擎的分發(fā)代理，當(dāng)前負(fù)責(zé)調(diào)度的分發(fā)代理出現(xiàn)故障時，分發(fā)代理會故障轉(zhuǎn)移到集群中的其他節(jié)點，從而避免了使用網(wǎng)關(guān)架構(gòu)所引入的單點故障點，除此之外，該類產(chǎn)品的特點是：

a) 負(fù)載均衡是基于每個客戶端的獨立請求，默認(rèn)規(guī)則是將查詢優(yōu)先分發(fā)到集群中負(fù)載低的服務(wù)器，也可以自定義規(guī)則，將某些特定業(yè)務(wù)分發(fā)到集群中的某一臺，比如將報表相關(guān)的查詢分發(fā)給集群中的特定服務(wù)器。

b) 采用Share-Nothing架構(gòu)，對數(shù)據(jù)進(jìn)行冗余，從而保證了數(shù)據(jù)的安全性

c) 數(shù)據(jù)庫同步機制采用日志Redo的方式，在日志同步之前對日志進(jìn)行壓縮，保證了同步效率

d) 在集群中任意節(jié)點出現(xiàn)故障時，會被自動剝離出節(jié)點，由剩余運行正常的節(jié)點繼續(xù)提供服務(wù)，從而保證了最小停機時間

e) 負(fù)載均衡集群從宏觀上提高了吞吐量和性能

f) 該類集群不需要特殊的存儲設(shè)備，可以使用廉價的本地存儲，但由于數(shù)據(jù)冗余，因此相較于Share-Disk架構(gòu)而言，需要更多的存儲空間

c.沒有獨立網(wǎng)關(guān)

當(dāng)前市場上也存在下列一種基于數(shù)據(jù)實時同步的集群，其拓?fù)浣Y(jié)構(gòu)如下圖所示：

此系統(tǒng)由于沒有獨立的集群網(wǎng)關(guān)，因此本質(zhì)上簡化成了數(shù)據(jù)庫的實時備份系統(tǒng)，與實際的備份系統(tǒng)不同的是，它是工作在數(shù)據(jù)庫應(yīng)用層。此系統(tǒng)的特點：

a) 沒有獨立的集群網(wǎng)關(guān)，通過主節(jié)點的轉(zhuǎn)發(fā)來實行查詢的負(fù)載均衡。在系統(tǒng)壓力大的情況下，集群主機會形成性能瓶頸，無論是CPU、內(nèi)存還是網(wǎng)絡(luò)帶寬，也可能是OS等系統(tǒng)內(nèi)核資源，都容易因到達(dá)臨界狀態(tài)而形成瓶頸。

b) 各節(jié)點數(shù)據(jù)實時一致，對于數(shù)據(jù)容錯有利。

c) 對客戶端沒有二進(jìn)制透明。

d) 負(fù)載均衡單元是數(shù)據(jù)庫連接。也就是說，在客戶端登陸數(shù)據(jù)庫的時候，靜態(tài)地指定連接到某個集群節(jié)點，此后此連接上的全部請求一律發(fā)送到該數(shù)據(jù)庫上，因此在特殊情況下，可能會出現(xiàn)這樣的場景：所有客戶端的連接集中在集群主機上，這時候，集群主機不但承擔(dān)了客戶端的所有查詢，還需要實時同步數(shù)據(jù)到所有的集群從機，即集群主機的CPU為100%，而集群別的節(jié)點CPU可能為0%，這樣整個系統(tǒng)的性能會受到嚴(yán)重影響。

e) 由于使用的是分布式事務(wù)機制(MSDTC)確保數(shù)據(jù)的實時一致性，因此數(shù)據(jù)同步的性能比較慢，根據(jù)測試,會比SQL Server鏡像慢好幾倍。

f) 同樣地，此集群的節(jié)點數(shù)量也受到限制，也是以2到4個節(jié)點為宜。