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

背景

國內某大型稅務系統，業務應用分布式上云改造。

業務難題

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

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

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

難題剖析

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

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

調優前時延

現網時延(ms)

類生產時延(ms)

100并發

500ms ~ 4000ms

40ms ~ 80 ms

1并發

31ms

6ms

Ping測試

0.9ms ~ 1.2ms

0.3ms ~ 0.4ms

表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消息時延秒降10倍，就用華為云DMS

分布式消息服務 DMS 云計算

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。