MySQL JDBC驅(qū)動(dòng)bug怎么解決

本篇內(nèi)容介紹了“MySQL JDBC驅(qū)動(dòng)bug怎么解決”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

1.1      問題背景

公司是做電商系統(tǒng)的，整個(gè)系統(tǒng)搭建在華為云上。系統(tǒng)設(shè)計(jì)的時(shí)候，考慮到后續(xù)的用戶和訂單數(shù)量比較大，需要使用一些大數(shù)據(jù)庫的組件。關(guān)系型數(shù)據(jù)庫這塊，考慮到后續(xù)數(shù)據(jù)量的快速增長，不是直接寫入MySQL，而是使用了華為云的分布式數(shù)據(jù)庫中間件DDM。

使用了DDM之后，可以在業(yè)務(wù)不感知的情況下，直接增加MySQL讀實(shí)例的個(gè)數(shù)，線性提升讀性能。也支持中間件層面的分庫分表，提供海量關(guān)系型數(shù)據(jù)庫的操作。簡直是為電商系統(tǒng)貼身定制的。

DDM自身是以集群形式提供服務(wù)的，對(duì)業(yè)務(wù)開放的是多個(gè)連接IP地址。需要有一層負(fù)載均衡。如果使用傳統(tǒng)的加LB的形式做負(fù)載均衡，會(huì)多一層中轉(zhuǎn)，有性能損耗。所以，直接使用了MySQL-JDBC提供的客戶端負(fù)載均衡能力。

業(yè)務(wù)通過MySQL-JDBC的Loadbalance能提訪問多個(gè)DDM節(jié)點(diǎn)。MySQL-JDBC提供負(fù)載均衡能力。

1.2      問題說明

使用MySQL客戶端負(fù)載均衡力能，一直運(yùn)行得好好，性能嗷嗷叫?？墒乔耙魂囎?，無故出現(xiàn)了業(yè)務(wù)請(qǐng)求失敗。我是負(fù)責(zé)電商訂單模塊的，涉及到真實(shí)的Money，這個(gè)問題嚇了寶寶一身冷汗。。趕緊查看后臺(tái)日志，發(fā)現(xiàn)是訪問DDM出現(xiàn)了異常，二話不說直接提了工單給華為云DDM服務(wù)。

[WARN] [2018-07-08 23:11:29] [MySqlValidConnectionChecker:isValidConnection()] [DubboServerHandler-172.31.0.146:8080-thread-64-txId=00000000657615aa] Unexpected error in ping

java.lang.reflect.InvocationTargetException

         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

         at java.lang.reflect.Method.invoke(Method.java:498)

         at com.alibaba.druid.pool.vendor.MySqlValidConnectionChecker.isValidConnection(MySqlValidConnectionChecker.java:98)

         at com.alibaba.druid.pool.DruidAbstractDataSource.testConnectionInternal(DruidAbstractDataSource.java:1252)

         at com.alibaba.druid.pool.DruidDataSource.getConnectionDirect(DruidDataSource.java:981)

不得不說，華為云的服務(wù)還是很好的，不到半個(gè)小時(shí)就聯(lián)系了我，還跟我一起排查問題。

將我們業(yè)務(wù)的日志取下來，和DDM的支撐人員一起分析，發(fā)現(xiàn)報(bào)錯(cuò)如下：

根本原因竟然是MySQL驅(qū)動(dòng)的bug，導(dǎo)致StackOverflow本地棧溢出導(dǎo)致，真是誤會(huì)了DDM服務(wù)，抱歉了。

Caused by: java.lang.StackOverflowError

         at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:2360)

         at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:2344)

         at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:568)

         at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:626)

         at com.mysql.jdbc.Buffer.writeStringNoNull(Buffer.java:670)

         at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2636)

         at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2483)

         at com.mysql.jdbc.ConnectionImpl.setReadOnlyInternal(ConnectionImpl.java:4961)

         at com.mysql.jdbc.ConnectionImpl.setReadOnly(ConnectionImpl.java:4954)

         at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:381)

         at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:366)

         at com.mysql.jdbc.LoadBalancedConnectionProxy.pickNewConnection(LoadBalancedConnectionProxy.java:344)

         at com.mysql.jdbc.LoadBalancedAutoCommitInterceptor.postProcess(LoadBalancedAutoCommitInterceptor.java:104)

         at com.mysql.jdbc.MysqlIO.invokeStatementInterceptorsPost(MysqlIO.java:2885)

         at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2808)

         at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2483)

         at com.mysql.jdbc.ConnectionImpl.setReadOnlyInternal(ConnectionImpl.java:4961)

         at com.mysql.jdbc.ConnectionImpl.setReadOnly(ConnectionImpl.java:4954)

         at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:381)

         at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:366)

         at com.mysql.jdbc.LoadBalancedConnectionProxy.pickNewConnection(LoadBalancedConnectionProxy.java:344)

         at com.mysql.jdbc.LoadBalancedAutoCommitInterceptor.postProcess(LoadBalancedAutoCommitInterceptor.java:104)

         at com.mysql.jdbc.MysqlIO.invokeStatementInterceptorsPost(MysqlIO.java:2885)

。。。 此處省略10000行。。

從堆?？梢钥闯鰜?，某個(gè)異常，觸發(fā)了MySQL-JDBC的bug，導(dǎo)致循環(huán)調(diào)用，直至棧溢出。

在華為DDM支撐人員的建議下，對(duì)驅(qū)動(dòng)代碼進(jìn)行了反編譯，從反編譯的情況下，可以看到，的確是存在循環(huán)嵌套的可能。

Loadbalance輪詢連接 –>同步新老連接的狀態(tài) ->發(fā)送sql給服務(wù)端 -> Loadbalance輪詢連接。

相關(guān)代碼如下：

com/mysql/jdbc/LoadBalancedConnectionProxy.java的pickNewConnection()函數(shù)

for (int hostsTried = , hostsToTry = this.hostList.size(); hostsTried < hostsToTry; hostsTried++) {
    ConnectionImpl newConn = null;
    try {
        newConn = this.balancer.pickConnection(this, Collections.unmodifiableList(this.hostList), Collections.unmodifiableMap(this.liveConnections),
                this.responseTimes.clone(), this.retriesAllDown);

        if (this.currentConnection != null) {
            if (pingBeforeReturn) {
                if (pingTimeout == ) {
                    newConn.ping();
                } else {
                    newConn.pingInternal(true, pingTimeout);
                }
            }

            syncSessionState(this.currentConnection, newConn);
        }

        this.currentConnection = newConn;
        return;

    } catch (SQLException e) {
        if (shouldExceptionTriggerConnectionSwitch(e) && newConn != null) {
            // connection error, close up shop on current connection
            invalidateConnection(newConn);
        }
    }
}

syncSessionState()函數(shù)，在執(zhí)行完SQL之后，又會(huì)調(diào)用postProcess()函數(shù)，如此嵌套循環(huán)就來了。

if 
(!this.conn.getAutoCommit()) {

     
this.matchingAfterStatementCount = 
;

     } 
else 
{

 

     
if 
(this.proxy == 
null 
&& 
this.conn.isProxySet()) {

         MySQLConnection lcl_proxy = 
this.conn.getMultiHostSafeProxy();

         
while 
(lcl_proxy != 
null 
&& !(lcl_proxy 
instanceof 
LoadBalancedMySQLConnection)) {

             lcl_proxy = lcl_proxy.getMultiHostSafeProxy();

         }

         
if 
(lcl_proxy != 
null) {

             
this.proxy = ((LoadBalancedMySQLConnection) lcl_proxy).getThisAsProxy();

         }

 

     }

 

     
if 
(this.proxy != 
null) {

         if 
(this.matchingAfterStatementRegex == 
null 
|| sql.matches(this.matchingAfterStatementRegex)) {

             
this.matchingAfterStatementCount++;

         }

     }

     if 
(this.matchingAfterStatementCount >= 
this.matchingAfterStatementThreshold) {

         
this.matchingAfterStatementCount = 
;

         
try 
{

             
if 
(this.proxy != 
null) {

                 
this.proxy.pickNewConnection();

             }

 

         } 
catch 
(SQLException e) {

             }

     }

 }

這么明顯的bug，不太相信MySQL會(huì)沒有發(fā)現(xiàn)。當(dāng)前我們使用的是5.1.44版本的驅(qū)動(dòng)，查看了下最新的5.1.66的代碼，發(fā)現(xiàn)的確是修復(fù)了這個(gè)問題的，代碼如下：

public 
ResultSetInternalMethods postProcess(String sql, Statement interceptedStatement, ResultSetInternalMethods originalResultSet, Connection connection,

                                             int 
warningCount, 
boolean 
noIndexUsed, 
boolean 
noGoodIndexUsed, SQLException statementException) 
throws 
SQLException {

 

     if (!this.countStatements || StringUtils.startsWithIgnoreCase(sql, "SET") || StringUtils.startsWithIgnoreCase(sql, "SHOW")) 
{

         
return 
originalResultSet;

     }

通過過濾掉SET和SHOW語句，避免了循環(huán)嵌套的發(fā)生。

但是5.1.66又引入了新的bug，由于并不是每個(gè)調(diào)用postProcess的地方都有SQL，這里的代碼會(huì)拋空指針異常。MySQL JDBC的開發(fā)者都不做測(cè)試的嗎。。。

沒辦法，分析了下5.1.44的代碼，發(fā)現(xiàn)通過適當(dāng)?shù)恼{(diào)整loadBalanceAutoCommitStatementThreshold這個(gè)參數(shù)的數(shù)值，也可以避免循環(huán)嵌套的發(fā)生。我們的環(huán)境改成了5，修改之后，平穩(wěn)運(yùn)行1周，沒再出現(xiàn)過問題。

1.3      修改方案

loadBalanceAutoCommitStatementThreshold修改成了5，但是引入的問題是，如果業(yè)務(wù)包含一些比較耗時(shí)的SQL，可能會(huì)DDM的負(fù)載不均衡。不過，目前看來還好，DDM性能比較強(qiáng)勁。

“MySQL JDBC驅(qū)動(dòng)bug怎么解決”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！