MySQL中MaxIdleConns變成短連接的原因是什么

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)MySQL中MaxIdleConns變成短連接的原因是什么，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

 配置解讀

maxIdleCount      int                    // zero means defaultMaxIdleConns; negative means 0
maxOpen      int          // <= 0 means unlimited
maxLifetime    time.Duration     // maximum amount of time a connection may be reused
maxIdleTime       time.Duration          // maximum amount of time a connection may be idle before being closed

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

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

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

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

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

 源碼解析

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

我們可以看到，當(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í)過(guò)大，超過(guò)了最大空閑連接數(shù)的負(fù)載，那么新的連接在放入連接池的時(shí)候，會(huì)被無(wú)情的關(guān)閉，變成短連接，導(dǎo)致你的服務(wù)性能進(jìn)一步惡化。

實(shí)驗(yàn)

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

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

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

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

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

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

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

上述就是小編為大家分享的MySQL中MaxIdleConns變成短連接的原因是什么了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。