一个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轮询连接。
相关代码如下:
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);
syncSessionState()函数,在执行完SQL之后,又会调用postProcess()函数,如此嵌套循环就来了。
if (!this.conn.getAutoCommit()) {
this.matchingAfterStatementCount = 0;
// auto-commit is enabled:
} else {
这么明显的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的性能还是比较强劲的
欢迎工作一到五年的Java工程师朋友们加入Java架构开发:744677563
本群提供免费的学习指导 架构资料 以及免费的解答
不懂得问题都可以在本群提出来 之后还会有职业生涯规划以及面试指导
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
HyperLedger Fabric架构(6.2)
6.2.1 架构演进 Fabric架构经历了0.6版本到1.0版本的演进,架构上进行了重大改进,从0.6版本的结构简单演进到可扩展、多通道的设计,在架构上有了质的飞跃;从1.0版本以后,架构未做重大调整,到目前为止,最新发布为1.2版本。 Fabric 0.6版本架构主要是应用、成员管理和Peer的三角形关系,业务逻辑全部集中在Peer节点上,结构过于简单,只能用于一些商业场景的验证。 Fabric 1.0版本在0.6版本的基础上做了重大改进和重构,把承载过多业务的Peer节点进行拆分,将区块链的数据维护和共识服务器进行分离,共识服务从Peer节点中完全分离出来,独立为Orderer节点专门提供共识服务;membership从架构中分离出来形成Fabric-ca单独组件;在架构中加入了多通道(channel)结构,实现更为灵活的业务适应性,支持更强的配置功能和策略管理功能,进一步增强系统的灵活性和适应性。 图:架构演进 6.2.2 总体架构 总体架构核心部分由成员管理(Membership services)、共识服务(Consensus services)和智能合约(...
- 下一篇
千万级调用量微服务架构实践
微服务架构在大型电商中的运用 电商是促销拉动式的场景,也是价格战驱动的场景。618和双11都是典型的促销活动。其实都是在抢用户、扩市场占有率。在这样的场景之下,对秒杀、抢购是很热衷的玩法。 促销式的拉动对系统的挑战是什么呢? 可以从上图里看到:对高可用性的要求是非常高的,需要99.99%的高可用性。快速迭代对对系统容性的要求很高,从几万单变成几十万单、百万单,架构上不能影响快速迭代,所以有空中加油或者是高速公路换轮胎的说法。 另外,为了应对瞬间的海量访问(尤其是秒杀场景),系统需要高可伸缩(快速扩容和缩容),这些都是对系统的要求。 大型电商系统的架构 从下往上,数据层,埋点数据把用户行为数据,实时数据存储在NoSQL、关系型数据库、大数据平台 。 基础架构层 这层实际上是中间件和服务,包括MQ的消息、job的调试中心、sso联合登陆,还有发消息的,分布式的文件存储,用户上传的一些图片等等,除此之外还有应用监控的整个体系、自动发布的框架,支持到AB测试。 基础服务层 再上面一层就是基础服务层,这实际上是用基础架构层提供的组件和服务,加上一些业务逻辑,构建了一些公用的服务,包括OMS、PM...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS8编译安装MySQL8.0.19
- CentOS6,CentOS7官方镜像安装Oracle11G
- 2048小游戏-低调大师作品
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- Docker快速安装Oracle11G,搭建oracle11g学习环境