談到負載均衡大家肯定都能理解它的作用，那就是對大量的數(shù)據(jù)進行平均分配。那么在緩存服務器中，我們同樣也需要負載均衡的技術(shù)。下面我們就聽聽專家對緩存服務器負載均衡問題的看法和研究。

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

在數(shù)據(jù)庫服務器與WEB應用服務器之間,還多了一層,即數(shù)據(jù)庫緩存服務器｡在SQLServer數(shù)據(jù)庫中,就是利用這些緩存服務器來實現(xiàn)數(shù)據(jù)庫層面的負載均衡,來提高數(shù)據(jù)庫的查詢性能｡那么這個解決方案到底有什么特點呢?是如何來解決查詢操作這個瓶頸問題?在部署這個解決方案的時候需要注意哪些問題呢?不要著急,筆者會一一回答這些問題｡

數(shù)據(jù)查詢與數(shù)據(jù)更新分開走

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

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

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

在部署這個解決方案時,仍然有些數(shù)據(jù)庫管理員需要關注的內(nèi)容｡如以下這些內(nèi)容,數(shù)據(jù)庫管理員需要根據(jù)企業(yè)的實際情況來進行調(diào)整,以提高這個方案的價值｡

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

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

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

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