一般的負載均衡指的是服務器,現(xiàn)在要求數(shù)據(jù)庫級別實現(xiàn)負載均衡,像oracle的rac。

SQL Server 負載均衡集群

一個應用系統(tǒng)隨著業(yè)務量的提高,以及訪問量和數(shù)據(jù)流量的快速增長，各個核心部分的處理性能和計算強度也相應增大，使得單一設備根本無法承擔。在此情況下，如果扔掉現(xiàn)有設備去做大量的硬件升級，必將造成現(xiàn)有資源的浪費，而且下一次業(yè)務量的提升，又將導致再一次硬件升級的高額成本投入。于是，負載均衡機制應運而生。 對于應用系統(tǒng)的負載均衡的硬件和軟件比比皆是，因為應用服務器上的程序基本上認為是不變化的，而且一般的各個應用服務器上的程序是不交互的。因此應用服務器的負載均衡非常好做，只需要能夠進行分流的軟件或者硬件把多個客戶端的連接分配到多個應用服務器上去即可。

因為數(shù)據(jù)庫內(nèi)的數(shù)據(jù)是頻繁變化的，為了數(shù)據(jù)的一致性以及鎖資源的分配協(xié)調(diào)等，所以像應用服務器那樣只有分流是不夠的，各個節(jié)點需要頻繁的交互。這也是數(shù)據(jù)庫集群軟件難做的原因，當然也是賣的貴的原因了。

Oracle Real Application Clusters

對于數(shù)據(jù)庫負載均衡，大家最為耳熟能詳?shù)木褪荗racle RAC了。RAC是雙機并行服務器(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ù)嘏渲?，可以指定所有查詢都在客戶端進行緩存，這樣它們便可以在轉(zhuǎn)移后的節(jié)點上重新設置。

Moebius for SQL Server

截至到SQL Server 2008，微軟還是沒有推出負載均衡組件，只能靠第三方軟件來實現(xiàn)，好在這個軟件是幾個從微軟出來的人寫的，也算是個小小的巧合。說他們是微軟出來的并不是說他們的技術多厲害，而是他們利用SQL Server的一些內(nèi)部接口把集群做的非常透明， 無論是應用程序的調(diào)用還是開發(fā)/管理人員的使用都和面對一個數(shù)據(jù)庫一樣。

他們的實現(xiàn)原理是這樣的：和SQL Server鏡像一樣，每個數(shù)據(jù)庫節(jié)點都有自己的數(shù)據(jù)，也就是無共享磁盤架構(gòu)。他們稱之為“中間件”的程序宿主在數(shù)據(jù)庫的內(nèi)部，每個節(jié)點數(shù)據(jù)庫上寫入數(shù)據(jù)導致數(shù)據(jù)變化時，SQL Server會激活“中間件”，“中間件”把變化的數(shù)據(jù)同步到其他的節(jié)點上。其他節(jié)點發(fā)生變化也是一樣。因為“中間件”宿主在數(shù)據(jù)庫內(nèi)， 所以它能夠把每個同步的Session和SQL Server的Session綁定到一起，也就是使用戶的執(zhí)行和數(shù)據(jù)的同步成為一個原子操作，從而保證數(shù)據(jù)在每時每刻都是一致的。因此查詢可以隨便到每個機器上去查，從而做到了真正的負載均衡。

這是一種叫"數(shù)據(jù)庫路由器"的技術,這種技術的特點是靈活性好,但效率比RAC要低，畢竟RAC是在引擎里實現(xiàn)的不管怎么樣有比沒有強!