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

背景

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

業務難題

如上圖所示是模擬客戶的業務網頁構建的一個併發訪問模型。用戶在頁面點擊從而產生一個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的參數來決定的。