MySQL-JDBC驅動程式造成bug的問題說明

問題背景

公司是做電商系統的，整個系統搭建在華為雲端。系統設計的時候，考慮到後續的使用者和訂單數量比較大，需要使用一些大資料庫的元件。關係型資料庫這塊，考慮到後續資料量的快速成長，不是直接寫入MySQL，而是使用了華為雲端的分散式資料庫中間件DDM。 使用了DDM之後，可以在業務不感知的情況下，直接增加MySQL讀取實例的個數，線性提升讀取效能。也支援中間件層面的分庫分錶，提供海量關係型資料庫的操作。簡直是為電商系統貼身訂製的。

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

邏輯結構如下圖所示：

▲業務透過MySQL-JDBC的Loadbalance能提存取多個DDM節點。 MySQL-JDBC提供負載平衡能力。

問題說明

MySQL JDBC驅動的客戶端負載平衡能力，一直運作得好好，效能嗷嗷叫。可是前一陣子竟無故出現業務請求失敗。我是負責電商訂單模組的，涉及到真實的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的效能還是比較強勁的~

相關文章：

PHP驅動MongoDB整數問題的BUG與策略

##WebLogic下設定MySql資料庫的JDBC驅動程式

相關影片：

布林教育燕十八mysql入門影片教學

以上是MySQL-JDBC驅動程式造成bug的問題說明的詳細內容。更多資訊請關注PHP中文網其他相關文章！