[[431976]]

我們在之前也說了不少RocketMQ的知識點了，這一篇要說的是RocketMQ的消息的推拉機制，這個應該也是屬于面試的熱點，學起來吧

我們下面要說的推拉模式指的是broker和consumer之間的，producer和broker之間的模式是推的模式，也就是每次producer每次生產了消息，會主動推給broker

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

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

• 說一下推模式以及優缺點

推模式指的是broker將消息推向Consumer，也就是Consumer是被動的去接收這個消息，broker來將消息主動的去推給Consumer

那么這種模式的優缺點呢，大家可以想一下

很明顯的一個優點就是延遲小，實時性比較好，broker接收到消息之后就會立刻推送到Consumer，實時性相對來說是比較高的

還有一個優點其實就是簡化了Consumer端的邏輯，消費端不需要自己去處理這個拉取的邏輯，只需要監聽這個消息的topic，然后去專心的處理這個消息的業務邏輯即可

上面說的兩點是優點，那么有優點就肯定也會伴隨相應的缺點

第二點簡化了Consumer消費端的邏輯的同時，也就復雜化了broker端的邏輯，這其實也不算是優點或者缺點吧，算是這個模式的一個特點，需要根據場景來選擇自己合適的模式

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

就像一個生產線，本來只能接收的最大速度是10立方米每秒，結果呢，你每秒往生產線上扔100立方米每秒，那這個生產線可能就因為無法處理而直接崩盤

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

還以一個缺點就是消費者推出去之后，無法保證消息發送成功，push采用的是廣播模式，也就是只有服務端和客戶端都在同一個頻道的時候，推模式才可以成功的將消息推到消費者

• 分析一下拉模式以及優缺點

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

咋回事知道了，想想這樣的優缺點，知道了優缺點就對這個模式肯定了解的八九不離十了

最大的優點就是主動權掌握在Consumer這邊了，每個消費者的消費能力可能不一樣，消費者可以根據自身的情況來拉取消息的請求，如果消費者真的出現那種忙不過來的情況下，可以根據一定的策略去暫停拉取

服務端也相對來說輕松了，不需要去進行消息的處理邏輯了，你來了我就給你就好了，你要多少我就給你就好了，broker就是一個沒得感情的存儲機器

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

說完了優點，就需要說缺點了，拉模式需要Consumer對于服務端有一定的了解，主要的缺點就是實時性較差，針對于服務器端的實時更新的信息，客戶端還是難以獲取實時的信息

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

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

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

RocketMQ的使用的拉模式的使用特點

• 自己維護offsetStore：用戶需要自己保存消費者組的offset，比如存入Redis，或者調用MQ接口將其保存到broker端
• 自主選擇MessageQueue和offset進行消息拉取，用戶拉取消息的時候，用戶自己決定拉取哪個隊列從哪個offset開始，拉取多少消息

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

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

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

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

• RocketMQ是如何實現拉模式的

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

1、普通輪詢也是比較簡單的，就是定時發起請求，服務端收到請求之后無論是否有數據更新，都立即回復，也是屬于比較好理解的，實現起來也是比較簡單的，缺點呢，就是broker比較被動，需要不斷的處理客戶端連接的，就是服務端屬于一種有求必應的方式

2、長輪詢就是屬于對普通輪詢的一種優化，當然也是Consumer向服務端發起請求，而服務端收到后不會立即去響應，而是hold住客戶端連接，等待數據產生變更之后才會回復客戶端，或者超過指定時間還未產生變更

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

RocketMQ就是使用長輪詢來實現拉模式，Consumer發起pull請求之后，broker在處理請求拉取消息的時候，如果沒有查詢到消息則不會回復消費者任何消息，而是等待觸發通知消費者的這個事件

這里會有兩種觸發事件的條件：

1、DefaultMessageStore.ReputMessageService.run，一個定時任務，1毫秒一次，不斷的檢查是否有消息的產生，如果檢測到了，就會通知消費者，將新消息發送給消費者

2、PullRequestHoldService.run也是定時任務，5秒一次，該任務會逐個的檢查其中的請求，判斷是否有對應的新消息產生，如果有直接返回消費者，沒有就檢查該請求是否超過默認的長輪詢等待時間(默認15秒)，如果超出，則返回消費者

• 那pushConsumer怎么說?

RocketMQ中的PushConsumer其實底層也是拉模式實現的，只是一層披著拉模式的狼而已

因為RocketMQ后臺有個ReblanceService線程會自己偷偷的去找broker請求數據，這個線程會根據topic的隊列數量和當前的消費組的消費者個數進行負載均衡，每個隊列產生的請求都會放入到阻塞隊列中

然后有一個PullMessageService線程不斷的從該阻塞隊列中獲取請求，然后通過網絡請求broker，這樣算是實現了一種準實時的拉取消息

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