中軟獨家中標稅務核心征管系統，全國34個省國/地稅。電子稅務局15省格局。大數據×××局點，中國軟件電子稅務局技術路徑：核心征管 + 納稅服務 業務應用分布式上雲改造。

業務難題

如上圖所示是模擬客戶的業務網頁構建的一個並發訪問模型。用戶在頁面點擊從而產生一個HTTP請求，這個請求發送到業務生產進程，就會啟動一個投遞線程（Deliver Thread）調用Kafka的SDK接口，並發送3條消息到DMS（分布式消息服務），每條消息大小3k，需要等待3條消息都被處理完成後才會返回請求響應⑧。當消息達到DMS後，業務消費進程調用Kafka的消費接口把消息取出來，然後將每條消息放到一個響應線程(Response Thread)中進行處理，響應線程處理完後，通過HTTP請求通知投遞線程，投遞線程收到響應後返回回復響應。

100並發訪問時延500ms，未達成用戶業務要求

客戶提出了明確的要求：每1個兩核的ECS要能夠支撐並發訪問量100，每條消息端到端的時延範圍是幾十毫秒，即從生產者發送開始到接收到消費者響應的時間。客戶實測在使用了DMS的Kafka 隊列後，並發訪問量為100時時延高達到500ms左右，甚至出現達到秒級的時延，遠未達到客戶提出的業務訴求。相比較而言，客戶在Pod區使用的是自己搭建的原生Kafka，在並發訪問量為100時測試到的時延大約只有10~20ms左右。那麽問題來了，在並發訪問量相同的條件下，DMS的Kafka 隊列與Pod區自建的原生Kafka相比為什麽時延會有這麽大的差異呢？我們DMS的架構師 Mr. Peng對這個時延難題進行了一系列分析後完美解決了這個客戶難題，下面就讓我們來看看他的心路歷程。

難題剖析

根據模擬的客戶業務模型，Mr. Peng在華為雲類生產環境上也構造了一個測試程序，同樣模擬構造了100的並發訪問量，通過測試發現，類生產環境上壓測得到的時延平均時間在60ms左右。類生產上的時延數值跟客戶在真實生產環境上測到的時延差距這麽大，這是怎麽回事呢？問題變得撲朔迷離起來。

Mr. Peng當機立斷，決定就在華為雲現網上運行構造的測試程序，來看看到底是什麽原因。同時，在客戶的ECS服務器上，也部署了相同的測試程序，模擬構建了100的並發量，得到如下的時延結果對比表：

表1 華為雲現網與類生產環境時延對比表

從時延對比表的結果看來，Mr. Peng發現，即使在相同的並發壓力下，華為雲現網的時延比類生產差很多。Mr. Peng意識到，現在有2個問題需要分析：為什麽華為雲現網的時延會比類生產差？DMS的Kafka隊列時延比原生自建的Kafka隊列時延表現差的問題怎麽解決？Mr. Peng進行了如下分析：

時延分析

回歸問題的本質，DMS Kafka隊列的時延到底是怎麽產生的？可控的端到端時延具體分為哪些？Mr. Peng給出了如下的計算公式：

總時延 = 入隊時延 + 發送時延 + 寫入時延 + 復制時延 + 拉取時延

讓我們來依次了解一下，公式中的每一項都是指什麽。

入隊時延: 消息進入Kafka sdk後，先進入到要發送分區的隊列，完成消息打包後再發送，這一過程所用的時間。

發送時延：消息從生產者發送到服務端的時間。

寫入時延：消息寫入到Kafka Leader的時間。

復制時延：消費者只可以消費到高水位以下的消息（即被多個副本都保存的消息），所以消息從寫入到Kafka Leader，到所有副本都寫入該消息直到上漲至高水位這段時間就是消息復制的時延。

拉取時延：消費者采用pull模式拉取數據，拉取過程所用的時間。

（1） 入隊時延

現網是哪一部分的時延最大呢？通過我們的程序可以看到，入隊列等待發送時延非常大，如下圖:

即消息都等待在生產端的隊列中，來不及發送！
我們再看其他時延分析，因為無法在現網測試，我們分別在類生產測試了相同壓力的，測試其他各種時延如下：

（2） 復制時延
以下是類生產環境測試的1並發下的

從日誌上看，復制時延包括在remoteTime裏面，當然這個時間也會包括生產者寫入時延比較慢導致的，但是也從一定的程度反映復制時延也是提升性能時延的一個因素。

（3） 寫入時延

因為用戶使用的是高吞吐隊列，寫入都是異步落盤，我們從日誌看到寫入時延非常低(localTime)，可以判斷不是瓶頸。發送時延與拉取時延都是跟網絡傳輸有關系，這個優化主要是通過調TCP的參數來決定的。

Kafka實戰：如何把Kafka消息時延秒降10倍