數(shù)據(jù)庫(kù)連接數(shù)是數(shù)據(jù)庫(kù)中非常重要的概念之一，是大家學(xué)習(xí)數(shù)據(jù)庫(kù)知識(shí)的一個(gè)必須要掌握的，本文就為大家講解降低數(shù)據(jù)庫(kù)連接數(shù)的方法總結(jié)。

我們來(lái)看一下傳統(tǒng)三層下的序列圖

我們透過(guò)現(xiàn)象看一下本質(zhì)，圖中的依賴關(guān)系決定我們要有兩臺(tái)服務(wù)器【不考慮負(fù)載均衡的前提下】。這樣我們的問(wèn)題就來(lái)了，什么問(wèn)題那？接下來(lái)聽(tīng)我慢慢道來(lái)。
我們知道數(shù)據(jù)庫(kù)的鏈接以及連接池的分配是按照客戶端以及應(yīng)用程序來(lái)分配的。換句話說(shuō)“對(duì)于數(shù)據(jù)庫(kù)服務(wù)器在分配連接的時(shí)候是根據(jù)客戶端以及客戶端的應(yīng)用程序來(lái)分配的”，舉個(gè)例子我們有一臺(tái)服務(wù)器并且這臺(tái)服務(wù)器上運(yùn)行了三個(gè)進(jìn)程。這種情況下數(shù)據(jù)庫(kù)會(huì)分配三個(gè)Session，三個(gè)進(jìn)程中的鏈接以及連接池是不能共享的。看出問(wèn)題了吧。
問(wèn)題就是：當(dāng)我們隨著公司的業(yè)務(wù)增加而部署越來(lái)越多的應(yīng)用服務(wù)的時(shí)候數(shù)據(jù)庫(kù)的鏈接資源就會(huì)越來(lái)越少。當(dāng)連接資源到了一定程度的時(shí)候，數(shù)據(jù)庫(kù)的瓶頸就出來(lái)了，這時(shí)候眾多的請(qǐng)求在數(shù)據(jù)庫(kù)端排隊(duì)但是來(lái)自于客戶端的請(qǐng)求又不斷的壓到應(yīng)用程序服務(wù)器上，這樣我們的客戶端和數(shù)據(jù)庫(kù)群毆應(yīng)用程序服務(wù)器。
問(wèn)題的解決方案探索
我們?cè)谔剿鹘鉀Q方案的時(shí)候先來(lái)回顧一下問(wèn)題的場(chǎng)景：以洪水形式的請(qǐng)求壓到應(yīng)用程序服務(wù)器，接著應(yīng)用程序?qū)⑦@種壓力轉(zhuǎn)發(fā)到數(shù)據(jù)庫(kù)上。在數(shù)據(jù)庫(kù)上由于連接資源耗盡請(qǐng)求被大量積壓。這種積壓會(huì)增加應(yīng)用程序服務(wù)器的連接資源。應(yīng)用程序連接資源到一定程度下導(dǎo)致發(fā)送到應(yīng)用程序的請(qǐng)求在應(yīng)用程序端排隊(duì)積壓。這種情形就像浪涌。
為什么會(huì)出現(xiàn)這樣的問(wèn)題那？原來(lái)“當(dāng)我們?cè)黾討?yīng)用的同時(shí)數(shù)據(jù)庫(kù)的鏈接資源也在不斷的增加”。看來(lái)我們應(yīng)該找到一種方法，這種方法使得在增加新的應(yīng)用的時(shí)候連接資源不會(huì)增加。
那么我們是不是應(yīng)該統(tǒng)一來(lái)管理數(shù)據(jù)庫(kù)鏈接資源那？
答案是肯定的。來(lái)看看我們的方案看看能不能解決這個(gè)問(wèn)題。
部署圖

從圖中我們可以看到。我們把鏈接這種資源進(jìn)行了統(tǒng)一管理，就好像在數(shù)據(jù)庫(kù)前擋了一層代理。你直接向DAC要數(shù)據(jù)就可以了。
這就是我要為大家介紹的關(guān)于降低數(shù)據(jù)庫(kù)連接數(shù)的全部?jī)?nèi)容，可能知識(shí)還不夠全面，以后有機(jī)會(huì)，我還會(huì)繼續(xù)為大家介紹更多的知識(shí)，希望大家都能夠從中有所收獲。

【編輯推薦】

1. 改進(jìn)數(shù)據(jù)庫(kù)的查詢性能
2. 兩個(gè)有用的Oracle數(shù)據(jù)庫(kù)運(yùn)算
3. MySQL數(shù)據(jù)庫(kù)的主從配置
4. 常用內(nèi)存數(shù)據(jù)庫(kù)介紹