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在諸如此類的很是多的細微之處作的很是到位也有緣由吧。