分布式應(yīng)用連接池負(fù)載不均問題分析

1、負(fù)載均衡基本概念1.1負(fù)載均衡介紹在分布式架構(gòu)下隨著邏輯業(yè)務(wù)的快速發(fā)展，系統(tǒng)架構(gòu)也隨之變得龐大復(fù)雜，這中間對(duì)系統(tǒng)模塊的高并發(fā)、高可用、高擴(kuò)展性也提出了新的要求，比如服務(wù)路由、負(fù)載均衡等。負(fù)載均衡是指將負(fù)載（如計(jì)算任務(wù)、數(shù)據(jù)流量等）分?jǐn)偟蕉鄠€(gè)操作單元（如服務(wù)器、網(wǎng)絡(luò)設(shè)備等）上進(jìn)行執(zhí)行，以共同完成工作任務(wù)的一種技術(shù)。它建立在現(xiàn)有網(wǎng)絡(luò)結(jié)構(gòu)之上，提供了一種廉價(jià)、有效和透明的方法，可以擴(kuò)展網(wǎng)絡(luò)設(shè)備和服務(wù)器的帶寬、增加吞吐量、加強(qiáng)網(wǎng)絡(luò)數(shù)據(jù)處理能力，并提高網(wǎng)絡(luò)的靈活性和可用性。負(fù)載均衡在實(shí)現(xiàn)上有硬件和軟件兩種方式：硬件負(fù)載均衡器功能強(qiáng)大、穩(wěn)定性高，適合吞吐量大、高并發(fā)的流量負(fù)載，但是成本相對(duì)較高，并且擴(kuò)展性差；軟件負(fù)載部署上更加靈活，擴(kuò)展性高，但是性能和穩(wěn)定性相對(duì)較差。

1）硬件負(fù)載均衡設(shè)備F5負(fù)載均衡器（LTM）：F5BIG-IP負(fù)載均衡設(shè)備，支持4-7層負(fù)載均衡，具備負(fù)載均衡、應(yīng)用交換、狀態(tài)監(jiān)控等功能CDN負(fù)載均衡設(shè)備：專門用于CDN的負(fù)載均衡設(shè)備，通常采用多層架構(gòu)設(shè)計(jì)，包括全局負(fù)載均衡設(shè)備、局部負(fù)載均衡設(shè)備和緩存服務(wù)器等2）軟件負(fù)載均衡LVS：LVS軟件工作在網(wǎng)絡(luò)四層，通過vrrp協(xié)議轉(zhuǎn)發(fā)，有著高可用性、高性能、擴(kuò)展性的優(yōu)點(diǎn)，是Linux內(nèi)核的一款負(fù)載均衡軟件。Nginx：Nginx軟件工作在網(wǎng)絡(luò)七層，它屬于反向代理服務(wù)器，并且能夠支持虛擬主機(jī)，是開源的負(fù)載均衡軟件。HAProxy：HAProxy支持TCP和HTTP兩種代理模式，它是一個(gè)反向代理服務(wù)器，支持虛擬主機(jī)，也可以用作HTTPS代理、基于內(nèi)容的負(fù)載均衡等。1.2負(fù)載均衡常用的算法負(fù)載均衡是將業(yè)務(wù)流量負(fù)載到不同的服務(wù)器，而負(fù)載均衡算法就是實(shí)現(xiàn)在不同服務(wù)器之間分配網(wǎng)絡(luò)流量的邏輯。負(fù)載均衡算法的選擇會(huì)影響負(fù)載的分配機(jī)制，從而影響到性能和業(yè)務(wù)連續(xù)性，下面將介紹幾種常用的負(fù)載均衡算法。1）RoundRobin（輪詢算法）輪詢算法很簡(jiǎn)單，將前端請(qǐng)求按照順序輪流分配到后臺(tái)服務(wù)器上，不用關(guān)心后臺(tái)服務(wù)器的負(fù)載和實(shí)際連接情況。輪詢算法適用于后端服務(wù)器性能大致相當(dāng)?shù)那闆r，如果某臺(tái)機(jī)器性能異常承載不了這么多的流量，會(huì)造成業(yè)務(wù)訪問異常。當(dāng)然在實(shí)際的運(yùn)維工作中，會(huì)采用標(biāo)準(zhǔn)化的配置相同的服務(wù)器，以減少維護(hù)成本。如下圖所示流量請(qǐng)求安裝順序分發(fā)到后臺(tái)三個(gè)節(jié)點(diǎn)中，保證了流量均衡。2）WeightedRoundRobin（加權(quán)輪詢算法）加權(quán)輪詢算法是對(duì)輪詢算法的優(yōu)化，因?yàn)楹笈_(tái)服務(wù)器在配置和性能上有差異，在負(fù)載配置上將配置高、負(fù)載低的機(jī)器分配更高的權(quán)重，使其能處理更多的請(qǐng)求，而配置低、負(fù)載高的機(jī)器，則給其分配較低的權(quán)重，降低其系統(tǒng)負(fù)載。加權(quán)輪詢算法適用于后端具備不同負(fù)載容量的服務(wù)器，但是配置上更為復(fù)雜，也不利于標(biāo)準(zhǔn)化的配置。3）FastestResponseTime（最快響應(yīng)算法）最快響應(yīng)算法根據(jù)負(fù)載均衡器到每一個(gè)后端服務(wù)器節(jié)點(diǎn)的網(wǎng)絡(luò)響應(yīng)時(shí)間（RTT時(shí)延），并將下一個(gè)到達(dá)的連接請(qǐng)求動(dòng)態(tài)分配給響應(yīng)時(shí)間最短的節(jié)點(diǎn)。該算法能夠?qū)崿F(xiàn)應(yīng)用請(qǐng)求的快速響應(yīng)，提高業(yè)務(wù)請(qǐng)求的響應(yīng)時(shí)間，但是會(huì)出現(xiàn)請(qǐng)求集中在幾個(gè)響應(yīng)最快的節(jié)點(diǎn)上。如下圖所示，節(jié)點(diǎn)1和節(jié)點(diǎn)3的響應(yīng)時(shí)間為20ms、節(jié)點(diǎn)2為30ms，根據(jù)最快響應(yīng)算法，連接請(qǐng)求負(fù)載分發(fā)到節(jié)點(diǎn)1和節(jié)點(diǎn)3中。4）LeastConnections（最小連接算法）像前面的輪詢算法按照前端的請(qǐng)求次數(shù)均衡分配，實(shí)現(xiàn)后端服務(wù)器的負(fù)載均衡，但是實(shí)際上連接請(qǐng)求并不能真實(shí)反映服務(wù)器的負(fù)載情況。因此引入了最小連接算法，根據(jù)后端服務(wù)器當(dāng)前的連接情況，動(dòng)態(tài)的選取其中當(dāng)前積壓連接數(shù)最少的一臺(tái)服務(wù)器來處理當(dāng)前請(qǐng)求，盡可能的提高后臺(tái)服務(wù)器利用率。最小連接算法在本質(zhì)上是從后端服務(wù)器的角度來觀察系統(tǒng)的負(fù)載，能夠最大限度的利用后端服務(wù)器的資源，不足之處是負(fù)載均衡需要更多的資源來判斷后端服務(wù)的連接情況。如下圖所示最小連接算法的實(shí)現(xiàn)：除了上面4種，負(fù)載均衡算法還有隨機(jī)法、加權(quán)隨機(jī)法、源地址哈希法等不多介紹，實(shí)際應(yīng)用中輪詢算法和最小連接算法應(yīng)用的較多。2、Druid連接池介紹2.1Druid連接概覽Druid是開源的數(shù)據(jù)庫(kù)連接池，它結(jié)合了C3P0、DBCP、Proxool等DB池的優(yōu)點(diǎn)，同時(shí)加入了日志監(jiān)控，可以很好的監(jiān)控DB池連接和SQL的執(zhí)行情況。在druidDataSource中有一個(gè)重入鎖和衍生的兩個(gè)condition：一個(gè)監(jiān)控連接池是否為空，一個(gè)監(jiān)控連接池不為空。在druidDataSource中有兩個(gè)線程，一個(gè)生成連接CreateConnectionThread，一個(gè)回收連接DestoryConnectionThread。在創(chuàng)建、獲取、回收的時(shí)候都會(huì)使用這些鎖和condition。每次獲取Connection都會(huì)調(diào)用init，內(nèi)部使用inited標(biāo)識(shí)DataSource是否已經(jīng)初始化OK。每次獲取Connection都會(huì)需要進(jìn)行加鎖保證線程安全，所有操作都在加鎖后執(zhí)行。如果連接池內(nèi)沒有連接了，則調(diào)用empty.signal()，通知CreateThread創(chuàng)建連接，并且等待指定的時(shí)間，被喚醒之后再去查看是否有可用連接。2.2Druid參數(shù)配置說明

1）基本屬性name：配置這個(gè)屬性的意義在于，如果存在多個(gè)數(shù)據(jù)源，監(jiān)控的時(shí)候可以通過名字來區(qū)分開來。如果沒有配置，將會(huì)生成一個(gè)名字，格式是："DataSource-"+System.identityHashCode(this).url：連接數(shù)據(jù)庫(kù)的url，不同數(shù)據(jù)庫(kù)不一樣。例如：mysql:jdbc:mysql://04:3306/druid2、oracle:jdbc:oracle:thin:@5:1521:ocnautousername：連接數(shù)據(jù)庫(kù)的用戶名password：連接數(shù)據(jù)庫(kù)的密碼driverClassName：這一項(xiàng)可配可不配，如果不配置druid會(huì)根據(jù)url自動(dòng)識(shí)別dbType，然后選擇相應(yīng)的driverClassName2）連接池大小initialSize：初始化時(shí)建立物理連接的個(gè)數(shù)。初始化發(fā)生在顯示調(diào)用init方法，或者第一次getConnection時(shí)。缺省值為0maxActive：最大連接池?cái)?shù)量。缺省值為8minIdle：最小連接池?cái)?shù)量。缺省值為0maxWait：獲取連接時(shí)最大等待時(shí)間，單位毫秒。配置了maxWait之后，缺省啟用公平鎖，并發(fā)效率會(huì)有所下降，如果需要可以通過配置useUnfairLock屬性為true使用非公平鎖。缺省值為-13）連接檢測(cè)testOnBorrow：申請(qǐng)連接時(shí)執(zhí)行validationQuery檢測(cè)連接是否有效，做了這個(gè)配置會(huì)降低性能。缺省值為truetestOnReturn：歸還連接時(shí)執(zhí)行validationQuery檢測(cè)連接是否有效，做了這個(gè)配置會(huì)降低性能。缺省值為falsetestWhileIdle：建議配置為true，不影響性能，并且保證安全性。申請(qǐng)連接的時(shí)候檢測(cè)，如果空閑時(shí)間大于timeBetweenEvictionRunsMillis，執(zhí)行validationQuery檢測(cè)連接是否有效。缺省值為falsetimeBetweenEvictionRunsMillis：有兩個(gè)含義：1)Destroy線程會(huì)檢測(cè)連接的間隔時(shí)間，如果連接空閑時(shí)間大于等于minEvictableIdleTimeMillis則關(guān)閉物理連接。2)testWhileIdle的判斷依據(jù)。缺省值為60smaxEvictableIdleTimeMillis：連接空閑時(shí)間大于該值，不管minidle是多少都關(guān)閉這個(gè)連接。缺省值為7小時(shí)minEvictableIdleTimeMillis：連接空閑時(shí)間大于該值并且池中空閑連接數(shù)大于minidle則關(guān)閉這個(gè)連接。缺省值為30分鐘maxPoolPreparedStatementPerConnectionSize：要啟用PSCache，必須配置大于0，當(dāng)大于0時(shí)，poolPreparedStatements自動(dòng)觸發(fā)修改為true。在Druid中，不會(huì)存在Oracle下PSCache占用內(nèi)存過多的問題，可以把這個(gè)數(shù)值配置大一些，比如說100。缺省值為-1PhyTimeoutMillis：物理連接打開的時(shí)間超過這個(gè)超時(shí)時(shí)間，并且不再使用時(shí)會(huì)關(guān)閉這個(gè)物理連接，一般不建議打開validationQuery：用來檢測(cè)連接是否有效的sql，要求是一個(gè)查詢語句，常用select'x'。如果validationQuery為null，testOnBorrow、testOnReturn、testWhileIdle都不會(huì)起作用。缺省值為nullvalidationQueryTimeout：?jiǎn)挝唬好?，檢測(cè)連接是否有效的超時(shí)時(shí)間。底層調(diào)用jdbcStatement對(duì)象的voidsetQueryTimeout(intseconds)方法。缺省值為-1keepAlive：連接池中的minIdle數(shù)量以內(nèi)的連接，并且連接的空閑時(shí)間大于keepAliveBetweenTimeMillis但小于minEvictableIdleTimeMillis，則會(huì)執(zhí)行validationQuery來保持連接的有效性。缺省值為falsekeepAliveBetweenTimeMillis：打開KeepAlive時(shí)，當(dāng)連接的空閑時(shí)間超過該值，會(huì)使用validationQuery執(zhí)行一次查詢，檢查連接是否可用。缺省值為120s

4）緩存語句poolPreparedStatements：是否緩存preparedStatement，也就是PSCache。PSCache對(duì)支持游標(biāo)的數(shù)據(jù)庫(kù)性能提升巨大，比如說oracle。在mysql下建議關(guān)閉。缺省值為falsesharePrepareStatementsmaxPoolPreparedStatementPerConnectionSize：要啟用PSCache，必須配置大于0，當(dāng)大于0時(shí)，poolPreparedStatements自動(dòng)觸發(fā)修改為true。在Druid中，不會(huì)存在Oracle下PSCache占用內(nèi)存過多的問題，可以把這個(gè)數(shù)值配置大一些，比如說100。缺省值為-12.3連接?；詈突厥諜C(jī)制2.3.1連接?；顬榱朔乐挂粋€(gè)數(shù)據(jù)庫(kù)連接太久沒有使用，而被其它下層的服務(wù)關(guān)閉，druid中定義了KeepAlive選項(xiàng)，機(jī)制上與TCP中的類似。?；顧C(jī)制能夠保證連接池中的連接是真實(shí)有效的連接，假如遇到特殊情況導(dǎo)致連接不可用時(shí)，keepAlive機(jī)制將無效連接進(jìn)行驅(qū)逐。?；顧C(jī)制是由守護(hù)線程DestroyConnectionThread發(fā)起的，啟動(dòng)后守護(hù)線程會(huì)進(jìn)入無線循環(huán)，根據(jù)心跳間隔時(shí)間timeBetweenEvictionRunsMillis循環(huán)調(diào)用DestoryTask線程，默認(rèn)時(shí)間為60s。1）開啟KeepAlive//

一個(gè)連接在連接池中最小生存的時(shí)間dataSurce.setMinEvictableIdleTimeMillis(60

*

1000);單位毫秒//

開啟keepAlivedataSource.setKeepAlive(true);有兩個(gè)參數(shù)KeepAlive和MinEvictableIdleTimeMillis2）DruidDataSource中的兩個(gè)成員變量//

存放檢查需要拋棄的連接private

DruidConnectionHolder[]

evictConnections;//

用來存放需要連接檢查的存活連接privateDruidConnectionHolder[]keepAliveConnections;如果KeepAlive打開，當(dāng)一個(gè)連接的空閑時(shí)間超過keepAliveBetweenTimeMillis時(shí)，則會(huì)將此連接放入此連接放入keepAliveConnections數(shù)組，然后使用validationQuery執(zhí)行一次查詢。if(keepAlive&&idleMillis>=keepAliveBetweenTimeMillis){keepAliveConnections[keepAliveCount++]=connection;}…if(keepAliveCount>0){//keeporderfor(inti=keepAliveCount-1;i>=0;--i){DruidConnectionHolderholer=keepAliveConnections[i];Connectionconnection=holer.getConnection();holer.incrementKeepAliveCheckCount();booleanvalidate=false;try{this.validateConnection(connection);validate=true;}catch(Throwableerror){if(LOG.isDebugEnabled()){LOG.debug("keepAliveErr",error);}//skip

}如果本次validationQuery執(zhí)行失敗，則關(guān)閉該鏈接，并丟棄。2.3.2數(shù)據(jù)源收縮

在Druid數(shù)據(jù)源初始化的時(shí)候，會(huì)創(chuàng)建一個(gè)定時(shí)運(yùn)行的DestroyTask，該任務(wù)的主要目的是將已空閑時(shí)間滿足關(guān)閉條件的連接關(guān)閉。1）當(dāng)前連接存活時(shí)長(zhǎng)>配置的物理連接時(shí)間時(shí)長(zhǎng)，則放入evictConnectionsif(phyConnectTimeMillis>phyTimeoutMillis){evictConnections[evictCount++]=connection;continue;}2）空閑時(shí)間>最小驅(qū)逐時(shí)間if(idleMillis>=minEvictableIdleTimeMillis){if(checkTime&&i<checkCount){evictConnections[evictCount++]=connection;continue;}elseif(idleMillis>maxEvictableIdleTimeMillis){evictConnections[evictCount++]=connection;continue;}}…if(evictCount>0){for(inti=0;i<evictCount;++i){DruidConnectionHolderitem=evictConnections[i];Connectionconnection=item.getConnection();JdbcUtils.close(connection);destroyCountUpdater.incrementAndGet(this);}Arrays.fill(evictConnections,null);

}從代碼邏輯中可以看到，對(duì)于要關(guān)閉的空閑連接選擇邏輯如下：對(duì)于空閑時(shí)間>minEvictableIdleTimeMillis的連接，僅會(huì)關(guān)閉poolingCount-minIdle個(gè)，后面的連接不受影響處于>maxEvictableIdleTimeMillis的空閑連接則會(huì)直接關(guān)閉timeBetweenEvictionRunsMillis即為該定時(shí)任務(wù)運(yùn)行的間隔minEvictableIdleTimeMillis為可關(guān)閉連接的最小空閑時(shí)間2.4Druid連接生命周期Druid連接的生命周期從兩個(gè)維度去看：一個(gè)是應(yīng)用使用方，包括連接的申請(qǐng)、使用和關(guān)閉；一個(gè)是Druid自己管理的連接池，包括連接的創(chuàng)建和回收、?；顧C(jī)制等。具體如下所示：1）客戶端連接管理客戶端發(fā)起連接請(qǐng)求從Druid連接池申請(qǐng)連接，如果連接池內(nèi)連接不夠會(huì)調(diào)用CreateThread創(chuàng)建連接；客戶端拿到連接后，訪問數(shù)據(jù)庫(kù)進(jìn)行操作；連接操作完成后，釋放數(shù)據(jù)庫(kù)資源并close連接，這一步通常是由應(yīng)用主動(dòng)去做的，連接關(guān)閉后會(huì)回收，歸還給Druid連接池。2）Druid連接池管理Druid連接池設(shè)置最小連接數(shù)minIdle和最大連接數(shù)maxActive，最小連接數(shù)支持預(yù)熱功能，應(yīng)用每次申請(qǐng)連接的時(shí)候不需要重新初始化，高并發(fā)下可以提升性能；連接池會(huì)定時(shí)進(jìn)行連接?；?，KeepAlive的周期由timeBetweenEvictionRunsMillis控制（默認(rèn)值60s），當(dāng)發(fā)現(xiàn)連接的空閑時(shí)長(zhǎng)超過keepAliveBetweenTimeMillis（默認(rèn)值120s）時(shí)，會(huì)主動(dòng)發(fā)起鏈路?；?，一般是向數(shù)據(jù)庫(kù)發(fā)起SQL查詢，這個(gè)SQL語句可以自定義，通常為“select1fromdual”為了防止連接泄露，會(huì)定時(shí)回收空閑的連接，對(duì)于連接空閑時(shí)間大于minEvictableIdleTimeMillis（默認(rèn)為30分鐘）并且連接池中空閑連接數(shù)大于minIdle則關(guān)閉這個(gè)連接；如果連接空閑時(shí)間大于maxEvictableIdleTimeMillis（默認(rèn)值為7小時(shí)）則直接關(guān)閉連接從上可以看出，如果沒有連接?；?，當(dāng)設(shè)置minIdle后會(huì)有一部分在最小連接內(nèi)的連接因?yàn)榭臻e連接超時(shí)被關(guān)閉；當(dāng)然如果設(shè)置了KeepAlive并且當(dāng)?；畹臋z測(cè)頻率和keepAliveBetweenTimeMillis小于minEvictableIdleTimeMillis時(shí)，就不會(huì)出現(xiàn)空閑連接被關(guān)閉的情況。3、Druid連接池下數(shù)據(jù)庫(kù)負(fù)載不均問題3.1負(fù)載均衡后端成員啟動(dòng)先后問題在日常應(yīng)用系統(tǒng)架構(gòu)中，應(yīng)用->負(fù)載均衡->數(shù)據(jù)庫(kù)鏈路如下圖所示，應(yīng)用側(cè)配置連接池以提升性能、負(fù)載均衡如F5設(shè)備實(shí)現(xiàn)后端成員的管理，如后端成員UP/DOWN狀態(tài)監(jiān)測(cè)、流量負(fù)載分發(fā)等。負(fù)載均衡通過定時(shí)檢測(cè)機(jī)制如TCP監(jiān)聽或者SQL語句探測(cè)，以監(jiān)測(cè)后端成員的狀態(tài)，記錄到負(fù)載均衡設(shè)備中進(jìn)行管理。在上圖中部署了3個(gè)應(yīng)用服務(wù)器，每個(gè)上面配置最小空閑連接minIdle=20，總的初始化連接數(shù)有60個(gè)。當(dāng)后端成員維護(hù)或者升級(jí)等原因集體處于DOWN狀態(tài)然后再變成UP，但是對(duì)于負(fù)載均衡檢測(cè)到后端成員的UP狀態(tài)是有先后順序的，比如DB1最先處于UP狀態(tài)，后面其它DB陸續(xù)起來，這樣大量的連接最先到DB1節(jié)點(diǎn)，后面的DB節(jié)點(diǎn)也陸續(xù)有流量。整個(gè)過程可能很快，1~2s的時(shí)間，但是反映在后端成員的流量負(fù)載上已經(jīng)不均勻了（DB1=30、DB2=16、DB3=8、DB4=6）。如果此時(shí)DB1節(jié)點(diǎn)的資源和性能不足以支撐50%的業(yè)務(wù)流量，業(yè)務(wù)運(yùn)行會(huì)變慢或者數(shù)據(jù)庫(kù)請(qǐng)求失敗，造成業(yè)務(wù)連續(xù)性影響。上述問題的一個(gè)優(yōu)化方法是，如果是計(jì)劃內(nèi)的操作，在實(shí)施流程上進(jìn)行優(yōu)化，在后端成員都就緒以后再將業(yè)務(wù)負(fù)載接入，這樣會(huì)將流量請(qǐng)求相對(duì)均衡的負(fù)載到各個(gè)后端實(shí)例上。3.2負(fù)載均衡后端成員故障后接入另一個(gè)場(chǎng)景是負(fù)載均衡后端成員故障后再重新接入的問題，如上圖所示，3個(gè)應(yīng)用初始化連接為60，在負(fù)載均衡4個(gè)后端DB實(shí)例中平均為15。當(dāng)后端成員DB1故障后，其中的連接