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

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

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

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

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

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

采用這個(gè)方案需要注意的地方

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

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

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

為同步選擇合適的復(fù)制方案

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