sql server可以實現真正的負載平衡嗎？
sql server 不支持負載均衡。
sql server通過集群可以做到高可用性，集群也是共享磁盤的，不過不同與RAC的是，當前只有一個是活動的，另外一個備機。（當然你也可以做成A/A模式，不過這個不推薦，一旦出現故障，所有實例都轉移到一個服務器上，硬件資源是否滿足需要是個未知數。）；寫入做分片，這個需要應用跟着改，比如：WMS不同區域的數據在不同的服務器上。
oracle的rac也是共享磁盤的，所以性能提升也是有限的，雖然號稱能支持N個機器，但是通常只建議2台，越多越慢。（想想是共享磁盤就知道為啥了）
所以現在推出了大數據，非關系型數據庫，這也是未來的發展趨勢。
當今世界是一個信息化的世界，我們的生活中無論是生活、工作、學習都離不開信息系統的支撐。而信息系統的背后用於保存和處理最終結果的地方就是數據庫。因此數據庫系統就變得尤為重要，這意味着如果數據庫如果面臨問題，則意味着整個應用系統也會面臨挑戰，從而帶來嚴重的損失和后果。
如今“大數據”這個詞已經變得非常流行，雖然這個概念如何落地不得而知。但可以確定的是，隨着物聯網、移動應用的興起，數據量相比過去會有幾何級的提升，因此數據庫所需要解決的問題不再僅僅是記錄程序正確的處理結果，還需要解決如下挑戰：
- 當數據庫性能遇到問題時，是否能夠橫向擴展，通過添加服務器的方式達到更高的吞吐量，從而充分利用現有的硬件實現更好的投資回報率。
- 是否擁有實時同步的副本，當數據庫面臨災難時，可以短時間內通過故障轉移的方式保證數據庫的可用性。此外，當數據丟失或損壞時，能否通過所謂的實時副本（熱備）實現數據的零損失。
- 數據庫的橫向擴展是否對應用程序透明，如果數據庫的橫向擴展需要應用程序端進行大量修改，則所帶來的后果不僅僅是高昂的開發成本，同時也會帶來很多潛在和非潛在的風險。
面對上述挑戰一個顯而易見的辦法是將多個服務器組成一組集群，這樣一來就可以充分利用每一台服務器的資源並將客戶端負載分發到不同服務器上，隨着應用程序負載的增加，只需要將新的服務器添加到集群即可。
本篇文章將對集群的概念、形式以及目前主流的數據庫集群技術進行探討。
數據庫集群的形式
數據庫的集群和擴展不像應用程序擴展那樣容易，因為從數據庫端來說，一旦涉及到了集群，往往會涉及到數據庫層面的同步，因此從是否存在數據冗余這個角度來講，我們可以從大面上把數據庫集群分為以下兩種形式：
Share-Disk架構
Share-Disk架構是通過多個服務器節點共享一個存儲來實現數據庫集群，兩台機器最簡單的Share-Disk架構如圖1所示。
圖1.簡單的Share-Disk架構
在此基礎之上，Share-Disk架構又分為單活和雙活，雙活即為集群中的每一個節點都可以同時對外提供服務，而單活為集群中只有一個節點可對外提供服務，集群中的其他服務器作為冗余在“活”的節點出現故障時接替該服務器成為對外提供服務的節點。該類架構最典型的產品就是SQL Server Failover Cluster(SQL Server故障轉移集群)、NEC的EXPRESSCLUSTER、ROSE的ROSE HA。這種方式的弊端也是顯而易見的，如下：
- 硬件資源的嚴重浪費，同一時間集群中只有一台服務器活着，其他服務器只能作為冗余服務器。
- 集群無法提升性能，因為只有一台服務器可用
- 存儲方面存在單點故障，除非在存儲層級保證高可用，通常需要昂貴的SAN存儲。
因此該類方案僅僅可以做到服務器層面的高可用，無法帶來性能的提升，也無法解決存儲單點故障的問題。因此如果不搭配其他高可用或負載均衡的技術，存在的意義並不是很大。
另一類技術是Share-Disk中的雙活的技術，與單活技術不同的是，雙活的技術雖然也是共享磁盤，但集群中的所有節點都可以對外提供服務，典型的產品就是Oracle的RAC。RAC的技術性非常的高，因此需要水平比較高的人來運維系統。RAC設計的初衷並不是為了性能，而是為了高可用和可擴展性，如果應用程序不是針對RAC架構設計和開發的，則將應用程序遷移到RAC上由於block contention (block busy waits)可能會導致性能的急劇下降，並且節點越多性能下降越明顯。
Share-Nothing架構
Share-Nothing架構又分為兩種，首先是分布式架構。將數據庫中的數據按照某一標准分布到多台機器中，查詢或插入時按照條件查詢或插入對應的分區。
另一種是每一個節點完全獨立，節點之間通過網絡連接，通常是通過光釺等專用網絡。如圖2所示。
圖2.Share-Nothing冗余架構
在Share-Nothing架構中，每一個節點都擁有自己的內存和存儲，都保留數據的完整副本。通常來說，又可以分為兩種，可以負載均衡和不可以負載均衡。
首先談談不可負載均衡的集群，在不可負載均衡的技術中，集群中的節點會被分為主節點和輔助節點，主節點向外提供服務，輔助節點作為熱備（二階段事務提交）或暖備（不需要保證事務同步），同時有可能使得輔助節點提供只讀的服務。使用這個架構的技術包括：SQL Server AlwaysOn，SQL Server Mirror，Oracle Data Guard這種架構帶來的好處包括：
- 輔助節點數據和主節點保持同步或准同步，當搭配第三方仲裁后，可以實現自動的故障轉移，從而實現了高可用
- 輔助節點由於和主節點完全獨立且數據同步或准同步，因此主節點出現數據損壞后，可以從輔助節點恢復數據（自動或手動）
- 由於Share-Nothing架構使用了本地存儲（或SAN），相較於Share-Disk架構在慢速網絡時有非常大的性能優勢
當然，弊端也顯而易見，因為輔助節點無法對外提供服務或只能提供只讀服務，因此該類集群的弊端包括：
- 擴展能力非常有限
- 對性能沒有提升，因為涉及到各節點的數據同步，甚至帶來性能的下降
- 輔助節點如果可讀，雖然提升性能，但需要修改前端應用程序，對應用程序不透明
另一類Share-Nothing架構中，是允許負載均衡的。所謂負載均衡就是就是將對數據庫的負載分布到集群中的多個節點上，在集群中的每一個節點都可以對外提供服務，從而達到更高的吞吐量，更好的資源利用率和更低的響應時間。前端通過代理進行調度。使用該類架構的技術包括：MySQL上的Amoeba(架構如圖3，摘自MySQL大師陳暢亮的博客：http://www.cnblogs.com/gaizai/archive/2012/06/12/2546755.html)，MySQL上的HA Proxy（如圖4所示），格瑞趨勢(www.grqsh.com)在SQL Server上的Moebius集群(如圖5所示)。
圖3.Amoeba
圖4.HA Proxy
圖5.Moebius集群
可負載均衡的Share-Nothing架構的好處是每台服務器都能提供服務，能充分利用現有資源，達到更高的吞吐量。其中Amoeba中可能會涉及到數據分片，數據分片的好處是對於海量數據的處理更加高效，但同時也引入了其他問題，比如說需要應用程序端對應數據分片進行調整、跨分片節點查詢的處理問題、每一個數據分片節點是否能夠承受各自業務負載的高峰問題等。該類架構需要實施的人員水平比較高，且需要應用層面做調整，因此更適合於互聯網企業。
另一類不涉及到數據分片的架構，比如一類可以使用組合方案，比如說Oracle RAC+F5。另一類是使用單個廠商提供的方案，比如說SQL Server上的Moebius。這類方案集群中的每個節點都會對外提供服務，因此有如下好處：
- 由於每一個節點都可以對外提供服務，因此可以提升性能
- 擴展性得到提升，可以通過向集群添加節點直接進行Scale-Out擴充
- 由於前端應用通過代理連接到集群，而集群中的每一個節點都保持完整的數據集，因此不存在分片不到位反而造成性能下降的問題，因此對應用程序端完全透明
但相比較於MySQL的數據分片，該類方案的弊端也顯而易見，因為每一個節點都需要完整的數據集，因此需要占用更多的存儲空間。
原文鏈接： http://www.cnblogs.com/CareySon/p/3627594.html