1:問題的引入
過億訪問量網站的性能瓶頸是什麼?相信有過經歷的朋友一定會告訴你,是資料訪問。有關資料訪問這個話題可以說是博大精深,我今天就只針對「如何降低資料庫的連接數」這個話題來說開去。
2:問題發生的場景
我們來看一下傳統三層下的序列圖

155A52016-0  

我們透過現象看一下本質,圖中的依賴關係決定我們要有兩台伺服器【不考慮負載均衡的前提下】。這樣我們的問題就來了,什麼問題那?接下來聽我慢慢道來。
我們知道資料庫的連結以及連接池的分配是按照用戶端以及應用程式來分配的。換句話說「對於資料庫伺服器在分配連接的時候是根據用戶端以及用戶端的應用程式來分配的」,舉個例子我們有一台伺服器並且這台伺服器上運行了三個進程。這種情況下資料庫會分配三個Session,三個進程中的連結以及連接池是不能共用的。看出問題了吧。
問題就是:當我們隨著公司的業務增加而部署越來越多的應用服務的時候資料庫的連結資源就會越來越少。當連接資源到了一定程度的時候,資料庫的瓶頸就出來了,這時候眾多的請求在資料庫端排隊但是來自于用戶端的請求又不斷的壓到應用程式伺服器上,這樣我們的用戶端和資料庫群毆應用程式伺服器。
3:問題的解決方案探索
我們在探索解決方案的時候先來回顧一下問題的場景:以洪水形式的請求壓到應用程式伺服器,接著應用程式將這種壓力轉發到資料庫上。在資料庫上由於連接資源耗盡請求被大量積壓。這種積壓會增加應用程式伺服器的連接資源。應用程式連接資源到一定程度下導致發送到應用程式的請求在應用程式端排隊積壓。這種情形就像浪湧。
為什麼會出現這樣的問題那?原來「當我們增加應用的同時資料庫的連結資源也在不斷的增加」。看來我們應該找到一種方法,這種方法使得在增加新的應用的時候連接資源不會增加。
那麼我們是不是應該統一來管理資料庫連結資源那?
答案是肯定的。來看看我們的方案看看能不能解決這個問題。
部署圖

155A55094-1  

從圖中我們可以看到。我們把連結這種資源進行了統一管理,就好像在資料庫前擋了一層代理。你直接向DAC要資料就可以了。
4:遺留問題
我們剩下兩個問題給讀者思考。
1:為什麼對DAC分組,分組的意義是什麼?
2:我們建立了資料中心,在這後面實際上就是存儲層。存儲層分為資料庫,檔以及記憶體。那麼我們的存儲層該如何設計那?



後記:隨後我會追加文章給大家介紹存儲層的設計。
 
創作者介紹
創作者 shadow 的頭像
shadow

資訊園

shadow 發表在 痞客邦 留言(0) 人氣()