前言

我们都知道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在诸如此类的非常多的细微之处做的非常到位也有原因吧。