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

從策劃到設(shè)計制作，每一步都追求做到細(xì)膩，制作可持續(xù)發(fā)展的企業(yè)網(wǎng)站。為客戶提供網(wǎng)站設(shè)計制作、成都網(wǎng)站制作、網(wǎng)站策劃、網(wǎng)頁設(shè)計、域名申請、網(wǎng)絡(luò)空間、網(wǎng)絡(luò)營銷、VI設(shè)計、 網(wǎng)站改版、漏洞修補(bǔ)等服務(wù)。為客戶提供更好的一站式互聯(lián)網(wǎng)解決方案,以客戶的口碑塑造優(yōu)易品牌,攜手廣大客戶,共同發(fā)展進(jìn)步。

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

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

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

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

難題剖析

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

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

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

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

時延分析

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

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

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

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

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

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

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

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

（1）  入隊時延

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

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

      我們再看其他時延分析，因為無法在現(xiàn)網(wǎng)測試，我們分別在類生產(chǎn)測試了相同壓力的，測試其他各種時延如下：

（2）  復(fù)制時延

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

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

（3）  寫入時延

因為用戶使用的是高吞吐隊列，寫入都是異步落盤，我們從日志看到寫入時延非常低(localTime)，可以判斷不是瓶頸

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

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