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

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

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

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

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

从堆栈可以看出来，某个异常，触发了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的开发者都不做测试的吗……

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。