前段時間系統在晚上突然會出現應用不可用的情況，只有經過長時間（大約10分鍾）或者應用重啟后，訪問才能再次正常。查看日志，其中報大量的數據庫連接異常。如下：
懷疑是數據庫連接有問題，查看數據庫日志后發現當時數據庫進行了一次主庫和備份庫之接的切換。為什么要做這個切換呢？這是由於數據庫那邊有一個HA機制。所謂HA機制就是數據庫的高可用性保障機制，目前是通過一個心跳機制，每隔一段時間會由備份庫去ping主庫，如果無法ping通，則會進行一次主庫和備份庫之間的切換。
一開始，認為這是由於數據庫重啟，導致了不能訪問數據庫從而導致了系統不可用。但是數據庫重啟時間只有20秒左右，應該無法導致這么長時間的不可用。然后在本地機器上安裝了mysql數據庫進行了測試發現，系統在數據庫重啟，正常可用之后仍然無法正常訪問。后發現這是由於在數據庫重啟之后，在連接池中已經在使用的連接均會失效，如果后續的訪問不幸取到這些連接的話，則仍然無法正常訪問數據庫。
那么如何使應用在數據庫連接失效之后，能夠將這些連接馬上失效，並取到可用的連接呢？其實很簡單，只需要在數據庫連接池配置中加一個配置項即可。目前看了一下各個應用，有三種不同的實現方式：
如果使用的proxool,則可以在數據庫的連接url中加一個autoReconnect參數即可，如下：
如果使用的是DBCP，則有兩種方式，如下：
方式A:使用先驗SQL來驗證連接是否可用。
方式B:使用異常捕獲來驗證連接是否可用。
DBCP中的兩種不同的配置方式，各有長處吧，用check-valid-connection-sql可以在連接失效時重新取得連接來盡量保證此次數據庫請求正常，而缺點是每次執行sql都要額外執行一次驗證sql；而exception-sorter-class- name雖然不用每次額外執行一條sql，但是在取到失效連接那次訪問依然不能使用。
參考資料：DBCP的配置項含義