前言
我們都知道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在諸如此類的非常多的細微之處做的非常到位也有原因吧。