分析MyBatis空閑連接探測的機制

這篇文章主要講解了“分析MyBatis空閑連接探測的機制”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“分析MyBatis空閑連接探測的機制”吧！

最近碰到個現象，某個應用，每天在21:00-23:00才會執行，連接數據庫執行操作，間隔性出現連接超時的錯誤，

Connection timed out (Read failed)

因為應用和數據庫是跨網段，咨詢了下，防火墻超時時間配置的是30分鐘，應用用的MyBatis連接池，相關配置如下，

相關參數解釋，如下所示，

POOLED– 這種數據源的實現利用“池”的概念將 JDBC  連接對象組織起來，避免了創建新的連接實例時所必需的初始化和認證時間。這種處理方式很流行，能使并發 Web 應用快速響應請求。

除了上述提到UNPOOLED下的屬性外，還有更多屬性用來配置POOLED的數據源：

poolMaximumActiveConnections – 在任意時間可存在的活動(正在使用)連接數量，默認值：10

poolMaximumIdleConnections – 任意時間可能存在的空閑連接數。

poolMaximumCheckoutTime – 在被強制返回之前，池中連接被檢出(checked out)時間，默認值：20000 毫秒(即 20  秒)

poolTimeToWait –  這是一個底層設置，如果獲取連接花費了相當長的時間，連接池會打印狀態日志并重新嘗試獲取一個連接(避免在誤配置的情況下一直失敗且不打印日志)，默認值：20000  毫秒(即 20 秒)。

poolMaximumLocalBadConnectionTolerance – 這是一個關于壞連接容忍度的底層設置，  作用于每一個嘗試從緩存池獲取連接的線程。如果這個線程獲取到的是一個壞的連接，那么這個數據源允許這個線程嘗試重新獲取一個新的連接，但是這個重新嘗試的次數不應該超過  poolMaximumIdleConnections 與 poolMaximumLocalBadConnectionTolerance 之和。默認值：3(新增于  3.4.5)

poolPingQuery – 發送到數據庫的偵測查詢，用來檢驗連接是否正常工作并準備接受請求。默認是“NO PING QUERY  SET”，這會導致多數數據庫驅動出錯時返回恰當的錯誤消息。

poolPingEnabled – 是否啟用偵測查詢。若開啟，需要設置 poolPingQuery 屬性為一個可執行的 SQL  語句(最好是一個速度非常快的 SQL 語句)，默認值：false。

poolPingConnectionsNotUsedFor – 配置 poolPingQuery  的頻率。可以被設置為和數據庫連接超時時間一樣，來避免不必要的偵測，默認值：0(即所有連接每一時刻都被偵測 — 當然僅當 poolPingEnabled 為  true 時適用)。

P.S.

https://mybatis.org/mybatis-3/zh/configuration.html#environments

按照這字面意思，一開始我們理解poolPingConnectionsNotUsedFor參數控制的是連接多久沒用，即處于空閑狀態，在參數poolPingEnabled開啟時，就會執行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)，則會執行poolPingQuery的SQL，此處就是"select 1 from  dual"，如果執行失敗，會關閉這個連接，

從應用日志，能看到這些信息，

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的連接探測機制，各有優缺點，優點就是會在一定程度保證應用正常的業務請求得到可用的連接，畢竟不可用的連接都已經被poolPingQuery定義的SQL測試了，一般情況下，不會讓正常的業務請求出現報錯，除非連接池沒任何可用的連接。缺點就是如果配置的poolPingConnectionsNotUsedFor很小，某些請求都會在執行之前先進行驗證，但是換個角度，如果是高并發，只要參數不是0，一般可能都不會滿足需要驗證的條件，如果設置為0，就可能會有很多pingQuery定義的SQL執行。而且，如果像上述單線程的操作，他會一個連接一個連接的嘗試，等待一個連接出現超時錯誤的時間間隔是15分鐘，這就很低效了。

對連接池的選擇和配置，確實得結合實際場景需求來決策。

通過這個問題，至少讓我明白，“自以為對的”機制正確還是錯誤，還是看他的實現，這才是最可靠的驗證，而且，通過他的邏輯，可以讓我們借鑒一些設計路徑，多考慮他這么做背后的意義和影響，更有助我們將其用到正確的場景。

感謝各位的閱讀，以上就是“分析MyBatis空閑連接探測的機制”的內容了，經過本文的學習后，相信大家對分析MyBatis空閑連接探測的機制這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！