[[431976]]

我們在之前也說了不少RocketMQ的知識(shí)點(diǎn)了，這一篇要說的是RocketMQ的消息的推拉機(jī)制，這個(gè)應(yīng)該也是屬于面試的熱點(diǎn)，學(xué)起來吧

我們下面要說的推拉模式指的是broker和consumer之間的，producer和broker之間的模式是推的模式，也就是每次producer每次生產(chǎn)了消息，會(huì)主動(dòng)推給broker

其實(shí)這個(gè)大家也應(yīng)該好理解，如果producer和broker之間交互用broker來拉取，就會(huì)怪怪的，每次消息都要存儲(chǔ)到producer的本地，然后等待broker來拉取，這個(gè)要取決于多個(gè)producer的可靠性，顯然這種設(shè)計(jì)是很糟糕的

我們下面要討論的是broker和consumer之間的交互是推還是拉，大家也可以自己先思考下到底是推還是拉

• 說一下推模式以及優(yōu)缺點(diǎn)

推模式指的是broker將消息推向Consumer，也就是Consumer是被動(dòng)的去接收這個(gè)消息，broker來將消息主動(dòng)的去推給Consumer

那么這種模式的優(yōu)缺點(diǎn)呢，大家可以想一下

很明顯的一個(gè)優(yōu)點(diǎn)就是延遲小，實(shí)時(shí)性比較好，broker接收到消息之后就會(huì)立刻推送到Consumer，實(shí)時(shí)性相對來說是比較高的

還有一個(gè)優(yōu)點(diǎn)其實(shí)就是簡化了Consumer端的邏輯，消費(fèi)端不需要自己去處理這個(gè)拉取的邏輯，只需要監(jiān)聽這個(gè)消息的topic，然后去專心的處理這個(gè)消息的業(yè)務(wù)邏輯即可

上面說的兩點(diǎn)是優(yōu)點(diǎn)，那么有優(yōu)點(diǎn)就肯定也會(huì)伴隨相應(yīng)的缺點(diǎn)

第二點(diǎn)簡化了Consumer消費(fèi)端的邏輯的同時(shí)，也就復(fù)雜化了broker端的邏輯，這其實(shí)也不算是優(yōu)點(diǎn)或者缺點(diǎn)吧，算是這個(gè)模式的一個(gè)特點(diǎn)，需要根據(jù)場景來選擇自己合適的模式

最大的一個(gè)缺點(diǎn)就是推送的速率和消費(fèi)的速率不好去匹配，這樣就是很糟糕的，你想，如果broker拿到消息就推給Consumer，不在乎Consumer的消費(fèi)能力如何，就往Consumer直接扔，那Consumer有可能會(huì)崩潰

就像一個(gè)生產(chǎn)線，本來只能接收的最大速度是10立方米每秒，結(jié)果呢，你每秒往生產(chǎn)線上扔100立方米每秒，那這個(gè)生產(chǎn)線可能就因?yàn)闊o法處理而直接崩盤

當(dāng)推送速率很快的時(shí)候，甚至都像DDos的攻擊一樣，消費(fèi)者就更難受了，不同的消費(fèi)者的消費(fèi)速率也是不一樣的，broker也很難平衡每個(gè)消費(fèi)者的速率，如果broker需要記住每個(gè)Consumer的消費(fèi)能力和速度的話，那broker的復(fù)雜度可就直線上升

還以一個(gè)缺點(diǎn)就是消費(fèi)者推出去之后，無法保證消息發(fā)送成功，push采用的是廣播模式，也就是只有服務(wù)端和客戶端都在同一個(gè)頻道的時(shí)候，推模式才可以成功的將消息推到消費(fèi)者

• 分析一下拉模式以及優(yōu)缺點(diǎn)

拉模式，也是同樣的道理，就是Consumer是主動(dòng)從broker拉取消息，哎，這次我Consumer主動(dòng)了，我不需要你來喂我了，我每過一段時(shí)間去你那里拿消息就好了，你也別在乎我的消費(fèi)速率了

咋回事知道了，想想這樣的優(yōu)缺點(diǎn)，知道了優(yōu)缺點(diǎn)就對這個(gè)模式肯定了解的八九不離十了

最大的優(yōu)點(diǎn)就是主動(dòng)權(quán)掌握在Consumer這邊了，每個(gè)消費(fèi)者的消費(fèi)能力可能不一樣，消費(fèi)者可以根據(jù)自身的情況來拉取消息的請求，如果消費(fèi)者真的出現(xiàn)那種忙不過來的情況下，可以根據(jù)一定的策略去暫停拉取

服務(wù)端也相對來說輕松了，不需要去進(jìn)行消息的處理邏輯了，你來了我就給你就好了，你要多少我就給你就好了，broker就是一個(gè)沒得感情的存儲(chǔ)機(jī)器

拉模式也更適合批量消息的發(fā)送，推模式是來一個(gè)消息就推一個(gè)，當(dāng)然也可以緩存一部分消息再推送，但是無法確定Consumer是否能夠處理這批推送的消息，拉模式則是Consumer主動(dòng)來告訴broker，這樣broker也可以更好的決定緩存多少消息用于批量發(fā)送

說完了優(yōu)點(diǎn)，就需要說缺點(diǎn)了，拉模式需要Consumer對于服務(wù)端有一定的了解，主要的缺點(diǎn)就是實(shí)時(shí)性較差，針對于服務(wù)器端的實(shí)時(shí)更新的信息，客戶端還是難以獲取實(shí)時(shí)的信息

畢竟消費(fèi)者是去拉取消息，消費(fèi)者怎么知道消息到了呢，所以消費(fèi)者能做的就是不斷的去拉取，但是又不能頻繁的去拉取，這樣也耗費(fèi)性能，因此就必須降低請求的頻率，請求間隔時(shí)間也就意味著消息的延遲

• RocketMQ最終的選擇呢，為什么是拉模式

RocketMQ最終決定的拉模式，kafka也是如此

RocketMQ的使用的拉模式的使用特點(diǎn)

• 自己維護(hù)offsetStore：用戶需要自己保存消費(fèi)者組的offset，比如存入Redis，或者調(diào)用MQ接口將其保存到broker端
• 自主選擇MessageQueue和offset進(jìn)行消息拉取，用戶拉取消息的時(shí)候，用戶自己決定拉取哪個(gè)隊(duì)列從哪個(gè)offset開始，拉取多少消息

為什么拉模式稍微更合適些呢，現(xiàn)在的消息隊(duì)列都有持久化消息的需求，削峰主要就是靠持久化來削的，也就是本身需要有個(gè)存儲(chǔ)的功能，它的使命就是接受消息，保存好消息，然后等著消費(fèi)者來拉取就好了

消費(fèi)者也是各種各樣，消費(fèi)者的能力也是參差不齊，所以broker不能和Consumer有太多依賴

拉模式也是有缺點(diǎn)的，上面我們也說過了，最大的缺點(diǎn)就是實(shí)時(shí)性比較差，所以RocketMQ也盡力的去操作減輕這些缺點(diǎn)

broker來消息的時(shí)候，broker會(huì)去提醒Consumer來消息了，需要來拉取消息了，總之，就是broke和Consumer相互打配合，下面會(huì)詳細(xì)說

• RocketMQ是如何實(shí)現(xiàn)拉模式的

拉模式指的是Consumer主動(dòng)去找broker拉取消息，拉取模式分為普通輪詢和長輪詢兩種方式

1、普通輪詢也是比較簡單的，就是定時(shí)發(fā)起請求，服務(wù)端收到請求之后無論是否有數(shù)據(jù)更新，都立即回復(fù)，也是屬于比較好理解的，實(shí)現(xiàn)起來也是比較簡單的，缺點(diǎn)呢，就是broker比較被動(dòng)，需要不斷的處理客戶端連接的，就是服務(wù)端屬于一種有求必應(yīng)的方式

2、長輪詢就是屬于對普通輪詢的一種優(yōu)化，當(dāng)然也是Consumer向服務(wù)端發(fā)起請求，而服務(wù)端收到后不會(huì)立即去響應(yīng)，而是hold住客戶端連接，等待數(shù)據(jù)產(chǎn)生變更之后才會(huì)回復(fù)客戶端，或者超過指定時(shí)間還未產(chǎn)生變更

其實(shí)說白了，就是對普通輪詢進(jìn)行一定程度的限制，客戶端可以隨時(shí)請求服務(wù)端，但是我并不一定立即回復(fù)你

RocketMQ就是使用長輪詢來實(shí)現(xiàn)拉模式，Consumer發(fā)起pull請求之后，broker在處理請求拉取消息的時(shí)候，如果沒有查詢到消息則不會(huì)回復(fù)消費(fèi)者任何消息，而是等待觸發(fā)通知消費(fèi)者的這個(gè)事件

這里會(huì)有兩種觸發(fā)事件的條件：

1、DefaultMessageStore.ReputMessageService.run，一個(gè)定時(shí)任務(wù)，1毫秒一次，不斷的檢查是否有消息的產(chǎn)生，如果檢測到了，就會(huì)通知消費(fèi)者，將新消息發(fā)送給消費(fèi)者

2、PullRequestHoldService.run也是定時(shí)任務(wù)，5秒一次，該任務(wù)會(huì)逐個(gè)的檢查其中的請求，判斷是否有對應(yīng)的新消息產(chǎn)生，如果有直接返回消費(fèi)者，沒有就檢查該請求是否超過默認(rèn)的長輪詢等待時(shí)間(默認(rèn)15秒)，如果超出，則返回消費(fèi)者

• 那pushConsumer怎么說?

RocketMQ中的PushConsumer其實(shí)底層也是拉模式實(shí)現(xiàn)的，只是一層披著拉模式的狼而已

因?yàn)镽ocketMQ后臺(tái)有個(gè)ReblanceService線程會(huì)自己偷偷的去找broker請求數(shù)據(jù)，這個(gè)線程會(huì)根據(jù)topic的隊(duì)列數(shù)量和當(dāng)前的消費(fèi)組的消費(fèi)者個(gè)數(shù)進(jìn)行負(fù)載均衡，每個(gè)隊(duì)列產(chǎn)生的請求都會(huì)放入到阻塞隊(duì)列中

然后有一個(gè)PullMessageService線程不斷的從該阻塞隊(duì)列中獲取請求，然后通過網(wǎng)絡(luò)請求broker，這樣算是實(shí)現(xiàn)了一種準(zhǔn)實(shí)時(shí)的拉取消息

源碼在PullMessageProcessor里面的processRequest方法，用來處理拉消息的請求，有消息返回，沒有消息就進(jìn)入了上述說的長輪詢過程，這部分源碼我就不截了，大家感興趣的可以去研究研究