1 背景

最近石墨文檔線上業(yè)務(wù)出現(xiàn)了一些性能問題，在突發(fā)流量情況下，有個(gè)業(yè)務(wù)性能急劇下降。該服務(wù)是依賴于數(shù)據(jù)庫(kù)的業(yè)務(wù)，會(huì)批量獲取數(shù)據(jù)庫(kù)里的數(shù)據(jù)。在經(jīng)過一系列的排查過程后，發(fā)現(xiàn)該服務(wù)到數(shù)據(jù)庫(kù)的連接數(shù)經(jīng)常超過MaxIdleConns，因此懷疑是數(shù)據(jù)庫(kù)的配置導(dǎo)致的性能問題，所以以下針對(duì)數(shù)據(jù)庫(kù)的代碼進(jìn)行了剖析，并做了相關(guān)實(shí)驗(yàn)。

2 配置解讀

maxIdleCountint//zeromeansdefaultMaxIdleConns;negativemeans0
maxOpen      int          // <= 0 means unlimited
maxLifetime    time.Duration     // maximum amount of time a connection may be reused
maxIdleTimetime.Duration//maximumamountoftimeaconnectionmaybeidlebeforebeingclosed

可以看到以上四個(gè)配置，是我們Go MySQL客戶端最重要的配置。

maxIdleCount 最大空閑連接數(shù)，默認(rèn)不配置，是2個(gè)最大空閑連接

maxOpen 最大連接數(shù)，默認(rèn)不配置，是不限制最大連接數(shù)

maxLifetime 連接最大存活時(shí)間

maxIdleTime 空閑連接最大存活時(shí)間

3 源碼解析

我們的場(chǎng)景是客戶端與MySQL建立的連接數(shù)經(jīng)常大于最大空閑連接數(shù)，這會(huì)導(dǎo)致什么問題？我們看下下圖中的源碼。

我們可以看到，當(dāng)最大空閑連接數(shù)小于客戶端與數(shù)據(jù)庫(kù)建立的連接數(shù)的時(shí)候，那么就會(huì)返回false，并且最大連接數(shù)關(guān)閉計(jì)數(shù)器加1。

然后上圖中，我們就可以看到，連接被關(guān)閉了（MySQL源碼里也不留點(diǎn)緩沖時(shí)間再關(guān)閉）。Go的MySQL客戶端這個(gè)操作，就會(huì)導(dǎo)致當(dāng)突發(fā)流量情況下，由于請(qǐng)求量級(jí)過大，超過了最大空閑連接數(shù)的負(fù)載，那么新的連接在放入連接池的時(shí)候，會(huì)被無情的關(guān)閉，變成短連接，導(dǎo)致你的服務(wù)性能進(jìn)一步惡化。

4 實(shí)驗(yàn)

4.1 模擬線上并發(fā)數(shù)大于MaxIdConns情況

測(cè)試代碼 , 為了檢測(cè)以上邏輯，假設(shè)了以下場(chǎng)景，設(shè)置最大連接數(shù)為100，最大空閑連接數(shù)為1，并發(fā)數(shù)為10的goroutine來請(qǐng)求數(shù)據(jù)庫(kù)。我們通過MySQL的stats的maxIdleClosed的統(tǒng)計(jì)，可以看到下圖，我們的連接不停的被關(guān)閉。

4.2 模擬線上并發(fā)數(shù)小于MaxIdConns情況

測(cè)試代碼 ，假設(shè)了以下場(chǎng)景，設(shè)置最大連接數(shù)為100，最大空閑連接數(shù)為20，并發(fā)數(shù)為10的goroutine來請(qǐng)求數(shù)據(jù)庫(kù)，可以看到下圖中，無MaxIdleClosed的關(guān)閉統(tǒng)計(jì)。

4.3 抓包驗(yàn)證線上并發(fā)數(shù)大于MaxIdConns情況

測(cè)試代碼 ，為了驗(yàn)證沒有理解錯(cuò)代碼，抓個(gè)包最穩(wěn)妥。我們將main函數(shù)里放個(gè)select{}，程序執(zhí)行完mysql的語句后，看下tcp狀態(tài)和抓包數(shù)據(jù)。

可以發(fā)現(xiàn)確實(shí)是tcp的狀態(tài)統(tǒng)計(jì)與MySQL客戶端的統(tǒng)計(jì)是一致的，并且存在fin包。

5 總結(jié)

當(dāng)突發(fā)流量情況下，由于請(qǐng)求量級(jí)過大，超過了最大空閑連接數(shù)的負(fù)載，那么新的連接在放入連接池的時(shí)候，會(huì)被關(guān)閉，將連接變成短連接，導(dǎo)致服務(wù)性能進(jìn)一步惡化。為了避免這種情況，下面列舉了，可以優(yōu)化的措施。

提前將maxIdleConns設(shè)大，避免出現(xiàn)短連接

做好mysql讀寫分離

提升mysql的吞吐量：精簡(jiǎn)返回字段，沒必要的字段不要返回，能夠夠快復(fù)用連接

吞吐量的包盡量不要太大，避免分包

優(yōu)化連接池，當(dāng)客戶端到MySQL的連接數(shù)大于最大空閑連接的時(shí)候，關(guān)閉能夠做一下延遲（官方不支持，估計(jì)只能自己實(shí)現(xiàn)）

讀請(qǐng)求的最好不要放MySQL里，盡量放redis里

6 測(cè)試代碼

https://github.com/gotomicro/test/tree/main/gorm

以上就是MySQL的MaxIdleConns不合理，會(huì)變成短連接的原因的詳細(xì)內(nèi)容，更多關(guān)于MySQL的MaxIdleConns不合理的資料請(qǐng)關(guān)注本站其它相關(guān)文章！

海外服務(wù)器租用

版權(quán)聲明：本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請(qǐng)保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非maisonbaluchon.cn所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習(xí)參考，不代表本站立場(chǎng)，如有內(nèi)容涉嫌侵權(quán)，請(qǐng)聯(lián)系alex-e#qq.com處理。