問題背景
公司是做電商系統的,整個系統搭建在華為雲上。系統設計的時候,考慮到後續的使用者和訂單數量比較大,需要使用一些大資料庫的組件。關係型資料庫這塊,考慮到後續資料量的快速增長,不是直接寫入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,這裡的代碼會拋null 指標異常。MySQL JDBC的開發人員都不做測試的嗎……
沒辦法,分析了下5.1.44的代碼,發現通過適當的調整loadBalanceAutoCommitStatementThreshold這個參數的數值,也可以避免迴圈嵌套的發生。我們的環境改成了5,修改之後,平穩運行1周,沒再出現過問題。
修改方案
loadBalanceAutoCommitStatementThreshold修改成了5,但是引入的問題是,如果業務包含一些比較耗時的SQL,可能會導致DDM的負載不均衡。不過,就目前情況來看,DDM的效能還是比較強勁的~
相關文章:
PHP驅動MongoDB整數問題的BUG和策略
WebLogic下配置MySql資料庫的JDBC驅動
相關視頻:
布爾教育燕十八mysql入門視頻教程