網站的運營離不開訪問量，一個沒有人氣的網站是沒有什么經營意義的。那么對于大量的訪問者和流量的服務器分配是至關重要的。那么，負載均衡技術就是這個問題***的解決手段。現在，我們就為大家介紹一下關于SQL Server 的負載均衡問題。

對于數據庫負載均衡,大家最為耳熟能詳的就是Oracle RAC了｡下面,我們先簡單了解Oracle RAC的實現方法｡

RAC是雙機并行服務器(8i及以前版本稱作Oracle Parallel Server,OPS),用來在集群環境下實現多機共享數據庫,以保證應用的高可用性,同時可以自動實現并行處理及均分負載,還能實現數據庫在故障時的排錯和無斷點恢復｡它可以自動進行負載平衡､故障修復和規劃停機時間,以支持高可用性應用程序｡若并行服務器中某節點失效,透明的應用程序容錯能夠把用戶自動轉接到另一節點上繼續運行,應用程序在用戶沒有察覺的情況下繼續執行｡這使周期性和非周期性發生故障的系統增大了連續可用性｡進程的失效可以完全透明地轉移到另一節點上去,通過適當地配置,可以指定所有查詢都在客戶端進行緩存,這樣它們便可以在轉移后的節點上重新設置｡
截至到SQL Server 2008,微軟還是沒有推出負載均衡組件,只能通過SQL Server的其他技術特性或者利用第三方組件來DIY,下面列出我在做項目時最常用到的幾個方案｡

端到端拓撲的事務性復制

SQL Server 2005對端到端(P2P)拓撲結構上事務性的復制加強了支持｡P2P的拓撲結構支持無限的發布服務器,它們彼此之間可以互相交換事務｡

P2P拓撲是SQL Server的一個巨大進步｡現在,多端點服務器可以更改數據,并且向其他的發布者復制事務｡這就是說,訂閱服務器不再被限制在主要的報告環境中,可以通過事務性負載全球共享的方式將服務器分布開來｡當用戶的數量增加的時候,只要簡單地向這個群體中添加服務器即可｡

除了將負載分布之外,這個拓撲結構還增加了可用性｡如果任何一個點的服務器不可達,則池中其他服務器就會共享這個負載,因為每個服務器都有其他所有服務器上可獲得的全部數據集合｡

注意:因為數據的同步是異步的,也就是說各個節點上的數據可能會是存在差異的,所以千萬不要把它當成真正的負載均衡｡ 它被設計出來是用來各個數據庫中心交換數據的,不是用來真正的做負載均衡的｡

鏡像+快照

鏡像和快照是SQL Server 2005的另外兩個新特性,鏡像的主要用途是高可用性,正常情況下鏡像數據庫是不可用的,就這么閑著顯然是太浪費了,可以對鏡像數據庫做個快照,然后把一些對于數據實時性要求不高的查詢轉移過來,這樣似乎也能分擔主庫的一些壓力｡

把這個方案也叫負載均衡方案實在是勉為其難(我也是隨大溜按照別人的思路歸納的),因為快照不能建立的太頻繁,所以它的數據延時要比復制還要長,以小時記,因此轉移過來的查詢只能是一些報表之類的查詢｡

Moebius for SQL Server

這個方案是一個第三方軟件,是從微軟出來的幾個人做的,說他們是微軟出來的并不是說他們的技術多厲害,而是他們利用SQL Server的一些內部接口把集群做的非常透明, 無論是應用程序的調用還是開發/管理人員的使用都和面對一個數據庫一樣｡

他們的實現原理是這樣的:和鏡像一樣,每個數據庫節點都有自己的數據,也就是無共享磁盤架構｡他們稱之為“中間件"的程序宿主在數據庫的內部,每個節點數據庫上寫入數據導致數據變化時,SQL Server會激活“中間件",“中間件"把變化的數據同步到其他的節點上｡其他節點發生變化也是一樣｡因為“中間件"宿主在數據庫內, 所以它能夠把每個同步的Session和SQL Server的Session綁定到一起,也就是使用戶的執行和數據的同步成為一個原子操作,從而保證數據在每時每刻都是一致的｡

因此查詢可以隨便到每個機器上去查,從而做到了真正的負載均衡｡

另外還包括什么高可用性和虛擬IP什么的,和Oracle RAC的比較像,我也沒有仔細研究｡我覺得這屬于附屬功能了,關鍵點還是保證多個數據庫如何能一致｡