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