網絡的使用越來越生活化，那么單一的負載均衡技術已經不能滿足日益緊張的網絡壓力。為了緩解這些壓力，我們提出了更多的要求，也改進了不少技術，當然，最多的，就是和其他技術相互來結合進行優化設置。現在我們就說一說緩存服務器和負載均衡技術的結合使用。

根據一些專家的調查分析,發現企業在使用數據庫的時候,90%以上主要用來查詢｡有些企業這個比例甚至更高｡也就說,用戶對數據庫的操作,其實更新操作占的比例很少｡大部分的操走都只是查詢操作｡如一些論壇,大部分用戶只會看貼,而不會發帖｡這就是一個典型的查詢操作比例大大超過更新操作比例的例子｡針對這種情況,其查詢操作往往是其數據庫性能的瓶頸｡如何有效提高查詢的性能,這就使各個數據庫專家在考慮的問題｡在SQL Server數據庫中,已經有了一個現成的解決方案｡數據庫管理員可以利用緩存服務器來提高數據庫的性能｡筆者這里就以SQLServer2008為例,談談如何利用緩存服務器來實現負載均衡,來提高數據庫的查詢效率｡

利用緩存服務器來負載均衡

如上圖,是一家著名的BBS論壇的數據庫架構｡首先其通過多臺WEB應用服務器來實現負載均衡｡這個方案跟數據庫架構關系不大,筆者不做過多闡述｡筆者要談的是,其在數據庫服務器與WEB應用服務器之間,還多了一層,即數據庫緩存服務器｡在SQLServer數據庫中,就是利用這些緩存服務器來實現數據庫層面的負載均衡,來提高數據庫的查詢性能｡那么這個解決方案到底有什么特點呢?是如何來解決查詢操作這個瓶頸問題?在部署這個解決方案的時候需要注意哪些問題呢?不要著急,筆者會一一回答這些問題｡

一､ 數據查詢與數據更新分開走

如上圖所示,如果用戶要查看某個帖子,其就會打開某個連接｡此時WEB應用服務器就會從后臺數據庫中查詢相關的記錄｡這里需要注意的是,由于其只是查看帖子,而不涉及到更新的操作,為此WEB應用服務器就只從緩存服務器中讀取數據｡這個緩存服務器中的記錄跟數據庫服務器的內容是同步的｡WEB應用服務器在從數據庫緩存服務器讀取數據之前,還會先判斷一下哪臺數據庫服務器比較空｡會優先連接到比較空閑的數據緩存服務器中,然后從這臺服務器中讀取數據｡所以,當訪問這個論壇的用戶比較多時,這個數據緩存服務器能夠實現負載均衡的需要｡

如果用戶看了某個帖子,現在需要發表一個評論,此時后臺數據庫會怎么操作呢?注意,當WEB應用服務器發送了一個Update更新操作的時候,其應用服務器會自動連接到數據庫服務器,而不會再連接到數據庫緩存服務器｡而是直接向數據庫服務器發送更新操走的語句｡當數據庫服務器更新了相關的內容之后,會與數據庫緩存服務器實現數據的同步｡從上圖中可以看出,整個數據查詢與數據更新WEB應用服務器是分兩條路走｡其實這就好像是公路上分道行駛,機動車走機動車道;非機動車走非機動車道｡如此的話,就不會因為非機動車比較慢,而影響到機動車的速度｡在這個方案中,將數據庫的更新操作與查詢操作分開來走,也是類似的道理｡在查詢時,數據流是單向流動的,所以能夠在很大程度上提高查詢的效率｡從而讓數據負載均衡的效果更加明顯｡總之,當某個應用程序查詢操作大大超過更新操作時,通過在多個數據庫間緩存只讀數據,并在數據庫間均勻連接客戶端以分發負載,則就可以向外擴展工作負荷的讀取分區,即實現負載均衡的目的｡

二､ 采用這個方案需要注意的地方

在部署這個解決方案時,仍然有些數據庫管理員需要關注的內容｡如以下這些內容,數據庫管理員需要根據企業的實際情況來進行調整,以提高這個方案的價值｡#p#

首先需要考慮數據緩存服務器與數據庫服務器之間同步的頻率問題｡這個同步操作是一把雙刃劍｡若同步的頻率太高,會影響數據庫服務器與緩存服務器的性能;若同步頻率比較低的話,則數據庫緩存服務器中的數據得不到及時的更新｡如此的話,用戶查詢時可能在短時間內無法獲取最新的數據｡所以,一般來說,系統滯后的時間應該盡量的短,即數據庫服務器的更新內容必須盡快與數據庫緩存服務器進行同步｡理想的狀態時,在更新數據庫服務器的同時更新數據庫緩存服務器｡但是,這么做是以犧牲數據庫與數據庫緩存服務器的性能為代價的｡為此數據庫管理員在實施這個解決方案時,往往不會這么做｡而是設置在一段時間之后同步｡如可以設置為10秒､60秒､300秒或者更長的時間后進行同步｡具體這個同步的時間間隔多少為好,沒有一個統一的標準｡這需要數據庫管理員根據企業對數據同步的要求不同而定｡一般來說,數據庫管理員在滿足用戶需要的前期下,可以將這個時間設置的相對長一點｡這可以避免因為過多的同步操作而降低了這個方案的價值｡其實,對于大部分用戶來說,60秒左右的時間差異還是可以接受的｡如在論壇中,一個人發帖后,在一分鐘之后看到一般不會有什么問題｡對于人的感覺來說,這個一分鐘時間不長｡但是對于數據庫服務器來說,這一分鐘可以做很多事情｡所以,適當延長這個同步時間,卻可以在很大程度上提高數據庫服務器性能｡這個時間的代價,有時候還是值得的｡

其次,在數據庫服務器與數據庫緩存服務器之間,應該建立比較直接的､快速的網絡連接｡當用戶比較多時,數據庫服務器與數據庫緩存服務器之間若發生同步操作,則會造成很多的網絡流量｡有時候同步操作發生時,影響這個工作的效率可能并不是數據庫服務器或者數據庫緩存服務器本身,而是他們之間的網絡連接｡由于其可用的帶寬跟不少數據庫服務器系統的吞吐量,從而影響到了同步操作的效率｡為此,在數據庫服務器與數據庫緩存服務器之間的網路連接,應該盡量的直接｡如最好不要在中間夾著其他的不必要的網絡設備;也最好不要在他們之間配備防火墻等安全策略｡這些安全策略與網絡設備都會在很大程度上影響到這個同步操作的效率｡另外,最好也不要有其他的應用服務來爭搶帶寬｡所以簡單的說,如果可能的話,在數據庫服務器上部署多張網卡,直接與數據庫源服務器實現雙機互聯,而那傳輸同步操作需要的數據,這是一個很不錯的手段｡由于其數據傳輸更直接､而且其他設備或者應用服務也會來爭奪其帶寬,同時又可以克服他們的非法攻擊｡為此,只要他們之間多距離比較短的話,采用這種方案可能效果會比較好,可以在最大程度內縮短這個同步操作所需要的時間,從而讓其他用戶盡早看到更新的數據｡

三、為同步選擇合適的復制方案

那么該如何實現數據庫服務器與緩存服務器之間的同步呢?在SQLServer數據庫中,有三個方案可供數據庫管理員選擇｡這三個方案分別為快照復制､合并復制與事務復制｡這三個復制模型各有各的特點｡不過從最終效果來看,其都可以實現數據庫服務器與數據庫緩存服務器之間的同步｡不過由于其內部的實現機制不同,為此其雖然結果相同,但是從性能等方面考慮,還是有差異的｡各種復制模型的原理與特點屬于基本知識的范疇,筆者在這里就不做過多闡述了｡筆者認為,在利用這個數據庫緩存服務器來實現負載均衡的方案中,最好采用事務復制的同步方案｡因為相比其他方案來說,事務日志能夠滿足事務的一致性､數據庫服務器系統比較大的吞吐量､同步時盡量少的開銷､以及系統比較短的滯后時間等等需求｡另外在有些企業中采用這個方案的話,還要考慮到表與記錄的過濾需求｡而通過事務復制的話,就可以實現對列和行的過濾｡而其他復制模型的話,只能夠部分滿足這些需求｡所以,筆者認為,在選擇數據同步方案時,可能選擇事務復制來實現同步,更加的合適｡不過最終是否真是如此,還是要求數據庫管理員根據企業的實際需要,然后分別采用幾個復制模型來進行測試,才能夠得出真正合理的結果｡