如何利用緩存服務(wù)器來負載均衡

申請免費試用、咨詢電話：400-8352-114

根據(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ù)庫管理員可以利用緩存服務(wù)器來提高數(shù)據(jù)庫的性能。筆者這里就以SQLServer2008為例，談?wù)勅绾卫镁彺娣?wù)器來實現(xiàn)負載均衡，來提高數(shù)據(jù)庫的查詢效率。

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

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

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

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

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

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

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

其次，在數(shù)據(jù)庫服務(wù)器與數(shù)據(jù)庫緩存服務(wù)器之間，應(yīng)該建立比較直接的、快速的網(wǎng)絡(luò)連接。當用戶比較多時，數(shù)據(jù)庫服務(wù)器與數(shù)據(jù)庫緩存服務(wù)器之間若發(fā)生同步操作，則會造成很多的網(wǎng)絡(luò)流量。有時候同步操作發(fā)生時，影響這個工作的效率可能并不是數(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è)備都會在很大程度上影響到這個同步操作的效率。另外，最好也不要有其他的應(yīng)用服務(wù)來爭搶帶寬。所以簡單的說，如果可能的話，在數(shù)據(jù)庫服務(wù)器上部署多張網(wǎng)卡，直接與數(shù)據(jù)庫源服務(wù)器實現(xiàn)雙機互聯(lián)，而那傳輸同步操作需要的數(shù)據(jù)，這是一個很不錯的手段。由于其數(shù)據(jù)傳輸更直接、而且其他設(shè)備或者應(yīng)用服務(wù)也會來爭奪其帶寬，同時又可以克服他們的非法攻擊。為此，只要他們之間多距離比較短的話，采用這種方案可能效果會比較好，可以在最大程度內(nèi)縮短這個同步操作所需要的時間，從而讓其他用戶盡早看到更新的數(shù)據(jù)。

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

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