共計 1459 個字符，預計需要花費 4 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

這篇文章給大家分享的是有關 MySQL-JDBC 驅動引起 bug 問題的示例的內容。丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，一起跟隨丸趣 TV 小編過來看看吧。

問題背景

公司是做電商系統的，整個系統搭建在華為云上。系統設計的時候，考慮到后續的用戶和訂單數量比較大，需要使用一些大數據庫的組件。關系型數據庫這塊，考慮到后續數據量的快速增長，不是直接寫入 MySQL，而是使用了華為云的分布式數據庫中間件 DDM。使用了 DDM 之后，可以在業務不感知的情況下，直接增加 MySQL 讀實例的個數，線性提升讀性能。也支持中間件層面的分庫分表，提供海量關系型數據庫的操作。簡直是為電商系統貼身定制的。

DDM 自身是以集群形式提供服務的，對業務開放的是多個連接 IP 地址。需要有一層負載均衡。如果使用傳統的加 LB 的形式做負載均衡，會多一層中轉，有性能損耗。所以，直接使用了 MySQL-JDBC 提供的客戶端負載均衡能力。

邏輯結構如下圖所示：

▲業務通過 MySQL-JDBC 的 Loadbalance 能提訪問多個 DDM 節點。MySQL-JDBC 提供負載均衡能力。

問題說明

MySQL JDBC 驅動的客戶端負載均衡能力，一直運行得好好，性能嗷嗷叫?？墒乔耙魂囎泳篃o故出現業務請求失敗。我是負責電商訂單模塊的，涉及到真實的 Money，這個問題可嚇了寶寶一身冷汗……

于是趕緊查看了后臺日志，發現是訪問 DDM 出現了異常，二話不說直接提了工單給華為云 DDM 服務。

不得不說，華為云的服務還是很好的，不到半個小時就有專門的工作人員聯系了我，還跟我一起排查問題。

將我們業務的日志取下來，和 DDM 的支撐人員一起分析，發現報錯如下：根本原因竟然是 MySQL 驅動的 bug，導致 StackOverflow 本地棧溢出導致……原來是一個 Bug 引發的血案，誤會了 DDM 服務，真是抱歉了

從堆?？梢钥闯鰜?，某個異常，觸發了 MySQL-JDBC 的 bug，導致循環調用，直至棧溢出。在華為 DDM 支撐人員的建議下，對驅動代碼進行了反編譯，從反編譯的情況下，可以看到的確是存在循環嵌套的可能。

Loadbalance 輪詢連接 – 同步新老連接的狀態 – 發送 sql 給服務端 – Loadbalance 輪詢連接。

相關代碼如下：

這么明顯的 bug，不太相信 MySQL 會沒有發現。當前我們使用的是 5.1.44 版本的驅動，查看了下最新的 5.1.66 的代碼，發現的確是修復了這個問題的，代碼如下：

通過過濾掉 SET 和 SHOW 語句，避免了循環嵌套的發生。

但是 5.1.66 又引入了新的 bug，由于并不是每個調用 postProcess 的地方都有 SQL，這里的代碼會拋空指針異常。MySQL JDBC 的開發者都不做測試的嗎……

沒辦法，分析了下 5.1.44 的代碼，發現通過適當的調整 loadBalanceAutoCommitStatementThreshold 這個參數的數值，也可以避免循環嵌套的發生。我們的環境改成了 5，修改之后，平穩運行 1 周，沒再出現過問題。

修改方案

loadBalanceAutoCommitStatementThreshold 修改成了 5，但是引入的問題是，如果業務包含一些比較耗時的 SQL，可能會導致 DDM 的負載不均衡。不過，就目前情況來看，DDM 的性能還是比較強勁的~

感謝各位的閱讀！關于“MySQL-JDBC 驅動引起 bug 問題的示例”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！