微服務(wù)架構(gòu)下，MySQL讀寫分離后，Druid連接池參數(shù)優(yōu)化實戰(zhàn)
前言
最近利用MHA做好Mysql讀寫分離后，時不時有用戶反饋后臺發(fā)布文章時，報程序“通用異常"，經(jīng)問題排查，里面涉及應(yīng)用JDBC連接池參數(shù)及Mysql參數(shù)調(diào)整問題。
問題回顧
異常日志描述：
從異常信息反映來看，問題關(guān)鍵有兩點
- 數(shù)據(jù)庫連接池超時設(shè)置大于wait_timeout
- 日志提示，可以通過驗證數(shù)據(jù)庫連接或者設(shè)置：autoReconnect=true 來避免此異常
從以上兩點可以推測
第一、應(yīng)用程序數(shù)據(jù)庫連接池超時參數(shù)設(shè)置有問題
第二、安裝Mysql數(shù)據(jù)庫時，對于Mysql的內(nèi)在參數(shù)wait_timeout沒有做實際場景的優(yōu)化處理
問題定位
wait_timeout參數(shù)具體用途
wait_timeout具體含義是服務(wù)器關(guān)閉非交互連接之前等待活動秒數(shù)。MySQL缺省配置情況下，wait_timeout的初始值是28800秒，也就是8小時。如果wait_timeout超時時間設(shè)置過大，在MySQL管理系統(tǒng)里會產(chǎn)生大量的SLEEP進(jìn)程無法及時釋放，會導(dǎo)致服務(wù)器系統(tǒng)性能下降;同時該參數(shù)設(shè)置過小，會導(dǎo)致Mysql處理某些事務(wù)未處理，連接不可用狀態(tài)。
也就是說如果在wait_timeout設(shè)置期間內(nèi)，數(shù)據(jù)庫連接Connection一直處于空閑等待狀態(tài)，mysql內(nèi)部會自動關(guān)閉此連接，而應(yīng)用程序無法感知到，依然認(rèn)為連接池合法持有該連接。當(dāng)應(yīng)用端再次用該連接來進(jìn)行數(shù)據(jù)庫操作時，就產(chǎn)生上述異常錯誤。
應(yīng)用端Druid數(shù)據(jù)庫連接池參數(shù)排查
發(fā)現(xiàn)連接池有個MaxWait參數(shù)設(shè)置過大：60000毫秒
- druidDataSource.setMaxWait(60000)
然后在CSDN上，發(fā)現(xiàn)有個同行碰到同樣的問題：
發(fā)現(xiàn)數(shù)據(jù)庫等待超時時間(wait_timeout)是28800s，也就是8小時，而應(yīng)用程連接池參數(shù)max-wait: 30000，所以導(dǎo)致項目判定該鏈接可用，而mysql判定該連接不可用導(dǎo)致連接失敗。
解決辦法
根據(jù)上面的分析思路，我們排查了Mysql生產(chǎn)庫，發(fā)現(xiàn)默認(rèn)Mysql超時時間(wait_timeout)也是28800s，但是應(yīng)用層連接池MaxWait參數(shù)設(shè)置成60000，于是我把MaxWait參數(shù)設(shè)置成10000，小于Mysql超時時間(wait_timeout)：28800 ，在測試環(huán)境等待8小時后，報錯消失了。
其他擴(kuò)展思路(來源網(wǎng)絡(luò))
思路一：在jdbc-url后添加 &autoReconnect=true，使用后無效，查的該方案只適用于Mysql4之前的版本有效
思路二：將mysql回收空閑連接的時間變長，mysql默認(rèn)回收時間是8小時，可以在mysql目錄下的my.ini中增加下面配置，將時間改為1天。單位是秒，最大好像是24天。 此配置會拖累數(shù)據(jù)庫性能，隨棄用該方案。
思路三：配置druid鏈接池，使用 validation-query test-on-borrow: true test-while-idle: true 三種屬性，每次獲取數(shù)據(jù)庫連接時判斷該連接是否可用。同時設(shè)置druidDataSource.setPhyTimeoutMillis參數(shù)
連接最大存活時間，默認(rèn)是-1(不限制物理連接時間)，從創(chuàng)建連接開始計算，如果超過該時間，則會被清理druidDataSource.setPhyTimeoutMillis(15000);
參考例子
目前項目中趨于穩(wěn)定的連接池參數(shù)優(yōu)化實戰(zhàn)，參考如下：
Druid連接池參數(shù)官方說明：
