一个MySQL-JDBC驱动bug引起的血案……

问题背景

公司是做电商系统的,整个系统搭建在华为上。系统设计的时候,考虑到后续的用户和订单数量比较大,需要使用一些大数据库的组件。关系型数据库这块,考虑到后续数据量的快速增长,不是直接写入MySQL,而是使用了华为云的分布式数据库中间件DDM。使用了DDM之后,可以在业务不感知的情况下,直接增加MySQL读实例的个数,线性提升读性能。也支持中间件层面的分库分表,提供海量关系型数据库的操作。简直是为电商系统贴身定制的。

DDM自身是以集群形式提供服务的,对业务开放的是多个连接IP地址。需要有一层负载均衡。如果使用传统的加LB的形式做负载均衡,会多一层中转,有性能损耗。所以,直接使用了MySQL-JDBC提供的客户端负载均衡能力。

逻辑结构如下图所示:

一个MySQL-JDBC驱动bug引起的血案……

▲业务通过MySQL-JDBC的Loadbalance能提访问多个DDM节点。MySQL-JDBC提供负载均衡能力。

问题说明

MySQL JDBC驱动的客户端负载均衡能力,一直运行得好好,性能嗷嗷叫。可是前一阵子竟无故出现业务请求失败。我是负责电商订单模块的,涉及到真实的Money,这个问题可吓了宝宝一身冷汗……

于是赶紧查看了后台日志,发现是访问DDM出现了异常,二话不说直接提了工单给华为云DDM服务。

一个MySQL-JDBC驱动bug引起的血案……

不得不说,华为云的服务还是很好的,不到半个小时就有专门的工作人员联系了我,还跟我一起排查问题。将我们业务的日志取下来,和DDM的支撑人员一起分析,发现报错如下:根本原因竟然是MySQL驱动的bug,导致StackOverflow本地栈溢出导致……原来是一个Bug引发的血案,误会了DDM服务,真是抱歉了……

一个MySQL-JDBC驱动bug引起的血案……
一个MySQL-JDBC驱动bug引起的血案……

从堆栈可以看出来,某个异常,触发了MySQL-JDBC的bug,导致循环调用,直至栈溢出。在华为DDM支撑人员的建议下,对驱动代码进行了反编译,从反编译的情况下,可以看到的确是存在循环嵌套的可能。

Loadbalance轮询连接 –>同步新老连接的状态 ->发送sql服务端 -> Loadbalance轮询连接。

相关代码如下:

com/mysql/jdbc/LoadBalancedConnectionProxy.java的pickNewConnection()函数

for (int hostsTried = 0, 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 == 0) {
                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()函数,在执行完SQL之后,又会调用postProcess()函数,如此嵌套循环就来了。

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

this.matchingAfterStatementCount = 0;

// auto-commit is enabled:

} 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) {
    // increment the match count if no regex specified, or if matches:
    if (this.matchingAfterStatementRegex == null || sql.matches(this.matchingAfterStatementRegex)) {
        this.matchingAfterStatementCount++;
    }
}
// trigger rebalance if count exceeds threshold:
if (this.matchingAfterStatementCount >= this.matchingAfterStatementThreshold) {
    this.matchingAfterStatementCount = 0;
    try {
        if (this.proxy != null) {
            this.proxy.pickNewConnection();
        }

    } catch (SQLException e) {
        // eat this exception, the auto-commit statement completed, but we could not rebalance for some reason.  User may get exception when using
        // connection next.
    }
}

}

这么明显的bug,不太相信MySQL会没有发现。当前我们使用的是5.1.44版本的驱动,查看了下最新的5.1.66的代码,发现的确是修复了这个问题的,代码如下:

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

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

// Don't count SETs neither SHOWs. Those are mostly used internally and must not trigger a connection switch.
if (!this.countStatements || StringUtils.startsWithIgnoreCase(sql, "SET") || StringUtils.startsWithIgnoreCase(sql, "SHOW")) {
    return originalResultSet;
}

通过过滤掉SET和SHOW语句,避免了循环嵌套的发生。但是5.1.66又引入了新的bug,由于并不是每个调用postProcess的地方都有SQL,这里的代码会抛空指针异常。MySQL JDBC的开发者都不做测试的吗……

没办法,分析了下5.1.44的代码,发现通过适当的调整loadBalanceAutoCommitStatementThreshold这个参数的数值,也可以避免循环嵌套的发生。我们的环境改成了5,修改之后,平稳运行1周,没再出现过问题。

修改方案

loadBalanceAutoCommitStatementThreshold修改成了5,但是引入的问题是,如果业务包含一些比较耗时的SQL,可能会导致DDM的负载不均衡。不过,就目前情况来看,DDM的性能还是比较强劲的~ 点击这里 ,免费体验一番吧!

原文 

http://blog.51cto.com/13739602/2153631

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 一个MySQL-JDBC驱动bug引起的血案……

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址