我今天,為什么會提出這個問題.因為在做過的項目中,有2個大項目,發現性能瓶頸都是出現在數據庫上. 當然這瓶頸出現在數據庫上,也有一部分原因是我們一些開發人員,在開發的時候,寫的語句有一定的問題. 但除了這些外,我們也確實發現,數據庫這一塊是我們的瓶頸來的,我們的應用程序有用F5負載均衡,但數據庫沒有做負載均衡.因為微軟的數據庫並沒有實現負載均衡,而用第三方的,也不是很放心.其實解決這個數據庫瓶頸,也是有幾個方面可做.
- 是使用緩存,把一些常用的,數據變化不大的數據放在緩存里面,這個我們當時在做優化的時候也有做,效果還是可以的.
- 是把數據庫分到不同的服務器上.我們當時才用的是多數據庫的方式.然而遺憾的是,我們當時做了很多誇庫查詢,主要是跟基礎庫的連接.所以這方案的實施成本會大很多.
- 是最原始的方法,就是增加服務器的配置了.
- 是進行讀寫分離,其實我覺的,這也是一個比較好的方案在解決sql server 數據庫的負載均衡.而這方案的成本也是比較低廉的. 不過這東西需要在編程的時候,就要設置讀和寫的連接分開.
有關讀寫分離,其實我也沒有真正的在實踐中操作過,不知道哪位網友有類似的經驗,跟大家分享一下,尤其在開發過程中配到過的問題,能跟大家分享一下,我只是通過查資料,得出我的讀寫分離方案.其中可能有什么錯誤的地方,也請各位網友,多多指教一下.我查了資料,查到的sql sever 的讀寫操作也有2種方案.
- 是,通過鏡像技術,通過只讀,訪問AlwaysOn的輔助副本. 不過這方案會有延時,而且時間會比較大.對於這種方案,我感覺比較適合於對數據敏感度不高的報表.
- 是通過事務復制的技術來做,這個東西雖然也會有一定的延時,但總的來說延時很小,基本上是達到實時的.對於大部分場景都是適合的. 除非是非常敏感的數據.如訪問量統計,簽入遷出(這時候的對於數據的讀和寫的操作,都只能針對主數據庫了).
因此只要我們在編程的時候,把讀和寫的連接分開,我們就可以在后期對數據庫實施讀寫分離的操作了.
以上是我關於sql server 讀寫分離操作的一些理解,當然也是還沒有實踐過的,只是寫出來,跟廣大網友共同探討一下.