怎么把Kafka消息時(shí)延秒降10倍

這篇文章主要為大家展示了“怎么把Kafka消息時(shí)延秒降10倍”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“怎么把Kafka消息時(shí)延秒降10倍”這篇文章吧。

業(yè)務(wù)難題

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

100并發(fā)訪問時(shí)延500ms，未達(dá)成用戶業(yè)務(wù)要求

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

難題剖析

根據(jù)模擬的客戶業(yè)務(wù)模型，Mr. Peng在華為云類生產(chǎn)環(huán)境上也構(gòu)造了一個(gè)測試程序，同樣模擬構(gòu)造了100的并發(fā)訪問量，通過測試發(fā)現(xiàn)，類生產(chǎn)環(huán)境上壓測得到的時(shí)延平均時(shí)間在60ms左右。類生產(chǎn)上的時(shí)延數(shù)值跟客戶在真實(shí)生產(chǎn)環(huán)境上測到的時(shí)延差距這么大，這是怎么回事呢？問題變得撲朔迷離起來。

Mr. Peng當(dāng)機(jī)立斷，決定就在華為云現(xiàn)網(wǎng)上運(yùn)行構(gòu)造的測試程序，來看看到底是什么原因。同時(shí)，在客戶的ECS服務(wù)器上，也部署了相同的測試程序，模擬構(gòu)建了100的并發(fā)量，得到如下的時(shí)延結(jié)果對(duì)比表：

表1  華為云現(xiàn)網(wǎng)與類生產(chǎn)環(huán)境時(shí)延對(duì)比表

從時(shí)延對(duì)比表的結(jié)果看來，Mr. Peng發(fā)現(xiàn)，即使在相同的并發(fā)壓力下，華為云現(xiàn)網(wǎng)的時(shí)延比類生產(chǎn)差很多。Mr. Peng意識(shí)到，現(xiàn)在有2個(gè)問題需要分析：為什么華為云現(xiàn)網(wǎng)的時(shí)延會(huì)比類生產(chǎn)差？DMS的Kafka隊(duì)列時(shí)延比原生自建的Kafka隊(duì)列時(shí)延表現(xiàn)差的問題怎么解決？Mr. Peng進(jìn)行了如下分析：

時(shí)延分析

      回歸問題的本質(zhì)，DMS Kafka隊(duì)列的時(shí)延到底是怎么產(chǎn)生的？可控的端到端時(shí)延具體分為哪些？Mr. Peng給出了如下的計(jì)算公式：

      總時(shí)延 =  入隊(duì)時(shí)延 + 發(fā)送時(shí)延 + 寫入時(shí)延 + 復(fù)制時(shí)延 + 拉取時(shí)延

      讓我們來依次了解一下，公式中的每一項(xiàng)都是指什么。

      入隊(duì)時(shí)延: 消息進(jìn)入Kafka sdk后，先進(jìn)入到要發(fā)送分區(qū)的隊(duì)列，完成消息打包后再發(fā)送，這一過程所用的時(shí)間。

      發(fā)送時(shí)延：消息從生產(chǎn)者發(fā)送到服務(wù)端的時(shí)間。

      寫入時(shí)延：消息寫入到Kafka Leader的時(shí)間。

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

      拉取時(shí)延：消費(fèi)者采用pull模式拉取數(shù)據(jù)，拉取過程所用的時(shí)間。

（1）  入隊(duì)時(shí)延

      現(xiàn)網(wǎng)是哪一部分的時(shí)延最大呢？通過我們的程序可以看到，入隊(duì)列等待發(fā)送時(shí)延非常大，如下圖:

      即消息都等待在生產(chǎn)端的隊(duì)列中，來不及發(fā)送！

      我們?cè)倏雌渌麜r(shí)延分析，因?yàn)闊o法在現(xiàn)網(wǎng)測試，我們分別在類生產(chǎn)測試了相同壓力的，測試其他各種時(shí)延如下：

（2）  復(fù)制時(shí)延

以下是類生產(chǎn)環(huán)境測試的1并發(fā)下的

從日志上看，復(fù)制時(shí)延包括在remoteTime里面，當(dāng)然這個(gè)時(shí)間也會(huì)包括生產(chǎn)者寫入時(shí)延比較慢導(dǎo)致的，但是也從一定的程度反映復(fù)制時(shí)延也是提升性能時(shí)延的一個(gè)因素。

（3）  寫入時(shí)延

因?yàn)橛脩羰褂玫氖歉咄掏玛?duì)列，寫入都是異步落盤，我們從日志看到寫入時(shí)延非常低(localTime)，可以判斷不是瓶頸

發(fā)送時(shí)延與拉取時(shí)延都是跟網(wǎng)絡(luò)傳輸有關(guān)系，這個(gè)優(yōu)化主要是通過調(diào)TCP的參數(shù)來決定的。

以上是“怎么把Kafka消息時(shí)延秒降10倍”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！