建站
咨詢
售后
建站咨詢
新聞中心
1、面試場景與面試技巧
金三銀四招聘季，一位粉絲朋友最近在螞蟻金服第二輪面試時遇到這樣一個問題：如果MQ消費(fèi)遇到瓶頸時該如何處理?。
目前成都創(chuàng)新互聯(lián)公司已為近1000家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)絡(luò)空間、網(wǎng)站托管、服務(wù)器租用、企業(yè)網(wǎng)站設(shè)計(jì)、青岡網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。
橫向擴(kuò)容，相比很多讀者與我這位朋友一樣會脫口而出，面試官顯然不會滿意這樣的回答，然后追問道：橫向擴(kuò)容是堆機(jī)器，還有沒有其他辦法呢?
在面試過程中，個人建議大家在聽到問題后稍作思考，不要立馬給出太直接的答案，而是應(yīng)該與面試官進(jìn)行探討，一方面可更深刻的理解面試官的出題初衷，同時可以給自己梳理一下思路。
消費(fèi)端遇到瓶頸，這是一個結(jié)果，但引起這個結(jié)果的原因是什么呢?在沒有弄清楚原因之前談優(yōu)化、解決方案都會顯得很蒼白。
在這樣的面試場景中，我們該如何探討交流呢?我的思路如下：
- 嘗試與面試官探討如何判斷消費(fèi)端遇到瓶頸
- 如何查找根因
- 提出解決方案
溫馨提示：為了本文觀點(diǎn)的嚴(yán)謹(jǐn)性，本文主要以RocketMQ為例進(jìn)行剖析。
2、如何判斷消費(fèi)端遇到瓶頸
在RocketMQ消費(fèi)領(lǐng)域中判斷消費(fèi)端遇到瓶頸通常有兩個重要的指標(biāo)：
- 消息積壓數(shù)量(延遲數(shù)量)
- lastConsumeTime
在開源版本的控制臺rocketmq-console界面中，可以查閱一個消費(fèi)端上述兩個指標(biāo)，如下圖所示：
- Delay：消息積壓數(shù)量，即消費(fèi)端還剩下多少消息未處理，該值越大，說明消費(fèi)端遇到瓶頸了。
- LastConsumeTime：表示上一次成功消費(fèi)的消息的存儲時間，該值離當(dāng)前時間越大，同樣能說明消費(fèi)端遇到瓶頸了。
那為什么會積壓呢?消費(fèi)端是在哪遇到瓶頸了呢?
3、如何定位問題
消費(fèi)端出現(xiàn)瓶頸，如何識別是客戶端的問題還是服務(wù)端的問題，一個最簡單的辦法是看集群內(nèi)其他消費(fèi)組是否也有積壓，特別是和有問題的消費(fèi)組訂閱同一個主題的其他消費(fèi)組是否有積壓，按照筆者的經(jīng)驗(yàn)，出現(xiàn)消息積壓通常是客戶端的問題，可以通過查詢 rocketmq_client.log加以證明：
- grep "flow" rocketmq_client.log
出現(xiàn)so do flow control 這樣的日志，說明觸發(fā)了消費(fèi)的限流，其直接觸發(fā)原因：就是消息消費(fèi)端積壓消息，即消費(fèi)端無法消費(fèi)已拉取的消息，為了避免內(nèi)存泄露，RocketMQ在消費(fèi)端沒有將消息處理完成后，不會繼續(xù)向服務(wù)端拉取消息，并打印上述日志。
那如何定位消費(fèi)端慢在哪呢?是卡在哪行代碼呢?
通常的排查方法是跟蹤線程棧，即利用jstack命令查看線程運(yùn)行情況，以此來探究線程的運(yùn)行情況。
通常使用的命令如下：
- ps -ef | grep java
- jstack pid > j1.log
通常為了對比，我一般會連續(xù)打印5個文件，從而可以在5個文件中查看同一個消費(fèi)者線程，其狀態(tài)是否變化，如果未變化，則說明該線程卡主，那就是我們重點(diǎn)需要關(guān)注的地方。
在RocketMQ中，消費(fèi)端線程以ConsumeMessageThread_開頭，通過對線程的判斷，如下代碼讓人為之興奮：
消費(fèi)端線程的狀態(tài)是RUNNABLE，但在5個文件中其狀態(tài)都是一樣，基本可以斷定線程卡在具體的代碼，從示例代碼中是卡在掉一個外部的http借口，從而加以解決，通常在涉及外部調(diào)用，特別是http調(diào)用，可以設(shè)置一個超時時間，避免長時間等待。
4、解決方案
其實(shí)根據(jù)第三步驟，大概率能明確是哪個地方慢，遇到了性能瓶頸，通常無非就是調(diào)第三方服務(wù)，數(shù)據(jù)庫等問題出現(xiàn)了瓶頸，然后對癥下藥。數(shù)據(jù)庫等性能優(yōu)化，并不在本文的討論范圍之內(nèi)，故這里可以點(diǎn)到為止，當(dāng)然面試官后續(xù)可能會繼續(xù)聊數(shù)據(jù)庫優(yōu)化等話題，這樣就實(shí)現(xiàn)了與面試官的交流互動，一環(huán)扣一環(huán)，技術(shù)交流氛圍友好，面試通過率大大提高。
最后，我還想和大家探討一個問題，出現(xiàn)消息積壓就一定意味著遇到消費(fèi)瓶頸，一定需要處理嗎?
其實(shí)也不然，我們回想一下為什么需要使用MQ，不就是利用異步解耦與削峰填谷嗎?例如在雙十一期間，大量突發(fā)流量匯入，此時很可能導(dǎo)致消息積壓，這正式我們的用意，用MQ抗住突發(fā)流量，后端應(yīng)用慢慢消費(fèi)，保證消費(fèi)端的穩(wěn)定，在積壓的情況下，如果tps正常，即問題不大，這個時候通常的處理方式就是橫向擴(kuò)容，盡可能的降低積壓，減少業(yè)務(wù)的延遲。
丁威，《RocketMQ技術(shù)內(nèi)幕》作者，RocketMQ社區(qū)優(yōu)秀布道師，主打成體系分享JAVA主流中間件，打造完備的互聯(lián)網(wǎng)架構(gòu)體系，目前涵蓋Java并發(fā)、微服務(wù)、消息、調(diào)度、數(shù)據(jù)異構(gòu)等領(lǐng)域，未來繼續(xù)關(guān)注監(jiān)控、在線診斷等領(lǐng)域。
本文轉(zhuǎn)載自微信公眾號「中間件興趣圈」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系中間件興趣圈公眾號。
文章標(biāo)題：MQ消費(fèi)端遇到瓶頸除了橫向擴(kuò)容外還有其他解決辦法?
當(dāng)前網(wǎng)址：http://www.5511xx.com/article/cdogjej.html
