隨着業務量的提高,以及訪問量和數據流量的快速增長，網絡各個核心部分的處理性能和計算強度也相應增大，使得單一設備根本無法承擔。在此情況下，如果扔掉現有設備去做大量的硬件升級，必將造成現有資源的浪費，而且下一次業務量的提升，又將導致再一次硬件升級的高額成本投入。於是，負載均衡機制應運而生。
對於數據庫負載均衡，大家最爲耳熟能詳的就是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的比較像，我也沒有仔細研究。我覺得這屬於附屬功能了，關鍵點還是保證多個數據庫如何能一致。
拋磚引玉，我只是簡單說了一下每個方案的實現原理，理論指導實踐，有了方法接下來就是重複的枯燥的實踐了。 祝大家實踐快樂，並最終招到自己心目中完美的解決方案。
對於數據庫負載均衡，大家最爲耳熟能詳的就是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的比較像，我也沒有仔細研究。我覺得這屬於附屬功能了，關鍵點還是保證多個數據庫如何能一致。
拋磚引玉，我只是簡單說了一下每個方案的實現原理，理論指導實踐，有了方法接下來就是重複的枯燥的實踐了。 祝大家實踐快樂，並最終招到自己心目中完美的解決方案。