一个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的性能仍是比较强劲的~

点击这里，免费体验一番吧！