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

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

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

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

【編輯推薦】

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