建站
咨詢
售后
建站咨詢
新聞中心
最近碰到個現象，某個應用，每天在21:00-23:00才會執(zhí)行，連接數據庫執(zhí)行操作，間隔性出現連接超時的錯誤，
創(chuàng)新互聯專業(yè)為企業(yè)提供定襄網站建設、定襄做網站、定襄網站設計、定襄網站制作等企業(yè)網站建設、網頁設計與制作、定襄企業(yè)網站模板建站服務，10余年定襄做網站經驗，不只是建網站，更提供有價值的思路和整體網絡服務。
- Connection timed out (Read failed)
因為應用和數據庫是跨網段，咨詢了下，防火墻超時時間配置的是30分鐘，應用用的MyBatis連接池，相關配置如下，
相關參數解釋，如下所示，
POOLED– 這種數據源的實現利用“池”的概念將 JDBC 連接對象組織起來，避免了創(chuàng)建新的連接實例時所必需的初始化和認證時間。這種處理方式很流行，能使并發(fā) Web 應用快速響應請求。
除了上述提到UNPOOLED下的屬性外，還有更多屬性用來配置POOLED的數據源：
poolMaximumActiveConnections – 在任意時間可存在的活動(正在使用)連接數量，默認值：10
poolMaximumIdleConnections – 任意時間可能存在的空閑連接數。
poolMaximumCheckoutTime – 在被強制返回之前，池中連接被檢出(checked out)時間，默認值：20000 毫秒(即 20 秒)
poolTimeToWait – 這是一個底層設置，如果獲取連接花費了相當長的時間，連接池會打印狀態(tài)日志并重新嘗試獲取一個連接(避免在誤配置的情況下一直失敗且不打印日志)，默認值：20000 毫秒(即 20 秒)。
poolMaximumLocalBadConnectionTolerance – 這是一個關于壞連接容忍度的底層設置， 作用于每一個嘗試從緩存池獲取連接的線程。如果這個線程獲取到的是一個壞的連接，那么這個數據源允許這個線程嘗試重新獲取一個新的連接，但是這個重新嘗試的次數不應該超過 poolMaximumIdleConnections 與 poolMaximumLocalBadConnectionTolerance 之和。默認值：3(新增于 3.4.5)
poolPingQuery – 發(fā)送到數據庫的偵測查詢，用來檢驗連接是否正常工作并準備接受請求。默認是“NO PING QUERY SET”，這會導致多數數據庫驅動出錯時返回恰當的錯誤消息。
poolPingEnabled – 是否啟用偵測查詢。若開啟，需要設置 poolPingQuery 屬性為一個可執(zhí)行的 SQL 語句(最好是一個速度非常快的 SQL 語句)，默認值：false。
poolPingConnectionsNotUsedFor – 配置 poolPingQuery 的頻率?？梢员辉O置為和數據庫連接超時時間一樣，來避免不必要的偵測，默認值：0(即所有連接每一時刻都被偵測 — 當然僅當 poolPingEnabled 為 true 時適用)。
P.S.
https://mybatis.org/mybatis-3/zh/configuration.html#environments
按照這字面意思，一開始我們理解poolPingConnectionsNotUsedFor參數控制的是連接多久沒用，即處于空閑狀態(tài)，在參數poolPingEnabled開啟時，就會執(zhí)行poolPingQuery定義的SQL主動探測。
如果按照這理解，poolPingConnectionsNotUsedFor設置了3000，即3秒，遠小于30分鐘防火墻超時的設置，不應該出現連接超時的現象。
我們懷疑過防火墻的配置，但從應用端看，并不是所有的請求都超時，而且防火墻端，沒看到什么異常。數據庫層，應該未設置過相關的配置。
原因是什么?
作為一款成熟的產品，不太可能因為bug，更多還是對他的理解存在偏差。
下載3.3.0的源碼，鏈接如下，
https://github.com/mybatis/mybatis-3/releases/tag/mybatis-3.3.0
搜索這幾個參數所在的文件，找到了PooledDataSource類，可以看到這三個參數都設置了初始值，
看下這個pingConnection方法，
如果連接未關閉，判斷邏輯如下，
1. poolPingConnectionsNotUsedFor的值>=0;
2. getTimeElapsedSinceLastUse()>poolPingConnectionsNotUsedFor;
getTimeElapsedSinceLastUse()定義如下，
lastUsedTimestamp是在構造函數PooledConnection中定義的，
PooledConnection會在獲取連接(popConnection)和回收連接(pushConnection)的時候調用，獲取連接和回收連接則會被getConnection()和invoke()調用，因此，(2)的意思是當前這個連接空閑的時間是否大于這個參數poolPingConnectionsNotUsedFor定義的時間。
3. 如果滿足條件(1)和(2)，則會執(zhí)行poolPingQuery的SQL，此處就是"select 1 from dual"，如果執(zhí)行失敗，會關閉這個連接，
從應用日志，能看到這些信息，
- Testing connection 0000000000 ...
- Execution of ping query 'select 1 from dual' failed: Connection timed out (Read failed)
這個問題的關鍵，就是這個pingConnection，在什么時候調用，就決定了poolPingConnectionsNotUsedFor什么時候起作用，可以看到，他是在這個isValid的方法中調用的，
而這個isValid是在每次獲取連接和回收連接時調用的，換句話說，他是被動調用，并不是我們認為的空閑時主動調用，所以這個應用，只是晚上會跑，空閑連接超過30分鐘是很正常的，
應用開了debug，這兩段之間的間隔時間，就是得到超時連接的時間，
經過單線程測試，大約在15分鐘，
因此，對這種testOnBorrow的連接探測機制，各有優(yōu)缺點，優(yōu)點就是會在一定程度保證應用正常的業(yè)務請求得到可用的連接，畢竟不可用的連接都已經被poolPingQuery定義的SQL測試了，一般情況下，不會讓正常的業(yè)務請求出現報錯，除非連接池沒任何可用的連接。缺點就是如果配置的poolPingConnectionsNotUsedFor很小，某些請求都會在執(zhí)行之前先進行驗證，但是換個角度，如果是高并發(fā)，只要參數不是0，一般可能都不會滿足需要驗證的條件，如果設置為0，就可能會有很多pingQuery定義的SQL執(zhí)行。而且，如果像上述單線程的操作，他會一個連接一個連接的嘗試，等待一個連接出現超時錯誤的時間間隔是15分鐘，這就很低效了。
對連接池的選擇和配置，確實得結合實際場景需求來決策。
通過這個問題，至少讓我明白，“自以為對的”機制正確還是錯誤，還是看他的實現，這才是最可靠的驗證，而且，通過他的邏輯，可以讓我們借鑒一些設計路徑，多考慮他這么做背后的意義和影響，更有助我們將其用到正確的場景。
當前文章：“自以為對的”MyBatis空閑連接探測的機制
文章位置：http://m.5511xx.com/article/djodcii.html
