DDM的成熟在一个细微之处的体现

前言

咱们都知道DDM是华为云的很是优秀的分布式数据库中间件，在性能、易用性等方面在业界是遥遥领先的。他的成熟不单单体如今具备快速水平平滑扩容，支持多种分布式事物类型等等这些高大上的特性上，也体如今DDM诸多的细微之处，今天我和你们分享一个在发展多年的mycat上存在，可是在DDM中不存在的一个不起眼的细微问题（小问题，大灾难，在IT行业的历史上不断重演，咱们要警钟长鸣）。这个问题是我在DDM上玩了好多sql以后，发现DDM是一个玩不死的小强，出于好奇也把一些在DDM上玩的sql放到了mycat上，不幸的是，第一条sql放到了mycat上执行以后，就出现了神奇一幕，下面看看个人排查过程吧。

 

排查过程

首先，个人测试代码以下，个人sql除了加了一段注释以外，好像再普通不过了。可是一执行发现好像是卡主了。

因而赶忙使用jstack查看测试应用的线程栈信息，以下：

 

由上图不难发现是卡在测试代码TestJDBC的25行上，也就是卡在了“ps.executeQuery()”这行代码上。固然也发现最终是卡在和mycat的通讯上。那么为啥mycat一直没有返回结果呢。我立刻到部署mycat的测试机上，查看日志，没有发现异常信息。因而顺手看了一下测试机器的资源使用状况，果真有意外发现，以下：

 

发现有一个java进程的cpu使用率很是高，在这里，他确定是mycat进程，由于在这个机器上，我只部署了mycat这一个java应用。不由要问，mycat到底在干啥，是哪个线程出现了问题。因而我执行了一下这样的一条命令：ps -mp 3403 -o THREAD,tid,time，想去看个究竟，命令中的3403是mycat进程的id，因而我发现了下图的信息。

 

发现3403进程中的线程3420消耗了很是高的CPU，接下来不难想到的是使用jstack命令去调出该mycat进程的线程栈信息，在执行jstack以前，咱们先将线程id(nid) 3420转成16进制的数字，由于在jstack中看到的nid（native thread id）是16进制显示的，转换方式以下：

 

那好，让咱们来看一下mycat进程的该线程的栈快照吧，以下：

 

原来问题出在了DruidMycatRouteStrategy这个类的724行，因而看一下mycat的源码，以下：

 

看到代码以后，是否是恍然大悟呢，问题就出在这个while循环的处理逻辑上。固然这个bug的fix也不复杂。对该问题解决方式有兴趣的朋友能够在该文章下留言，咱们能够交流一下。

 

结语

经过上面这样的一个问题，咱们不难发现，如今业界的分布式数据库中间件在大的特性上基本都能作到对齐，那么为何华为云分布式数据库中间件DDM做为后起之秀，显得更加成熟，给用户留下了更好的印象呢？我想可能跟DDM在诸如此类的很是多的细微之处作的很是到位也有缘由吧。