你必須知道的消息的推拉機(jī)制
大家好，我是Captain
我們?cè)谥耙舱f了不少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í)性相對(duì)來說是比較高的
還有一個(gè)優(yōu)點(diǎn)其實(shí)就是簡(jiǎn)化了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)簡(jiǎn)化了Consumer消費(fèi)端的邏輯的同時(shí)，也就復(fù)雜化了broker端的邏輯，這其實(shí)也不算是優(yōu)點(diǎn)或者缺點(diǎn)吧，算是這個(gè)模式的一個(gè)特點(diǎn)，需要根據(jù)場(chǎng)景來選擇自己合適的模式
最大的一個(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)就對(duì)這個(gè)模式肯定了解的八九不離十了
最大的優(yōu)點(diǎn)就是主動(dòng)權(quán)掌握在Consumer這邊了，每個(gè)消費(fèi)者的消費(fèi)能力可能不一樣，消費(fèi)者可以根據(jù)自身的情況來拉取消息的請(qǐng)求，如果消費(fèi)者真的出現(xiàn)那種忙不過來的情況下，可以根據(jù)一定的策略去暫停拉取
服務(wù)端也相對(duì)來說輕松了，不需要去進(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對(duì)于服務(wù)端有一定的了解，主要的缺點(diǎn)就是實(shí)時(shí)性較差，針對(duì)于服務(wù)器端的實(shí)時(shí)更新的信息，客戶端還是難以獲取實(shí)時(shí)的信息
畢竟消費(fèi)者是去拉取消息，消費(fèi)者怎么知道消息到了呢，所以消費(fèi)者能做的就是不斷的去拉取，但是又不能頻繁的去拉取，這樣也耗費(fèi)性能，因此就必須降低請(qǐng)求的頻率，請(qǐng)求間隔時(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拉取消息，拉取模式分為普通輪詢和長(zhǎng)輪詢兩種方式
? ? 1、普通輪詢也是比較簡(jiǎn)單的，就是定時(shí)發(fā)起請(qǐng)求，服務(wù)端收到請(qǐng)求之后無論是否有數(shù)據(jù)更新，都立即回復(fù)，也是屬于比較好理解的，實(shí)現(xiàn)起來也是比較簡(jiǎn)單的，缺點(diǎn)呢，就是broker比較被動(dòng)，需要不斷的處理客戶端連接的，就是服務(wù)端屬于一種有求必應(yīng)的方式
? ?2、長(zhǎng)輪詢就是屬于對(duì)普通輪詢的一種優(yōu)化，當(dāng)然也是Consumer向服務(wù)端發(fā)起請(qǐng)求，而服務(wù)端收到后不會(huì)立即去響應(yīng)，而是hold住客戶端連接，等待數(shù)據(jù)產(chǎn)生變更之后才會(huì)回復(fù)客戶端，或者超過指定時(shí)間還未產(chǎn)生變更
其實(shí)說白了，就是對(duì)普通輪詢進(jìn)行一定程度的限制，客戶端可以隨時(shí)請(qǐng)求服務(wù)端，但是我并不一定立即回復(fù)你
? ? ? ? ? ? ? ? ? ? ? ?
RocketMQ就是使用長(zhǎng)輪詢來實(shí)現(xiàn)拉模式，Consumer發(fā)起pull請(qǐng)求之后，broker在處理請(qǐng)求拉取消息的時(shí)候，如果沒有查詢到消息則不會(huì)回復(fù)消費(fèi)者任何消息，而是等待觸發(fā)通知消費(fèi)者的這個(gè)事件
這里會(huì)有兩種觸發(fā)事件的條件：
1、DefaultMessageStore.ReputMessageService.run，一個(gè)定時(shí)任務(wù)，1毫秒一次，不斷的檢查是否有消息的產(chǎn)生，如果檢測(cè)到了，就會(huì)通知消費(fèi)者，將新消息發(fā)送給消費(fèi)者
2、PullRequestHoldService.run也是定時(shí)任務(wù)，5秒一次，該任務(wù)會(huì)逐個(gè)的檢查其中的請(qǐng)求，判斷是否有對(duì)應(yīng)的新消息產(chǎn)生，如果有直接返回消費(fèi)者，沒有就檢查該請(qǐng)求是否超過默認(rèn)的長(zhǎng)輪詢等待時(shí)間（默認(rèn)15秒），如果超出，則返回消費(fèi)者
那pushConsumer怎么說？
RocketMQ中的PushConsumer其實(shí)底層也是拉模式實(shí)現(xiàn)的，只是一層披著拉模式的狼而已
因?yàn)镽ocketMQ后臺(tái)有個(gè)ReblanceService線程會(huì)自己偷偷的去找broker請(qǐng)求數(shù)據(jù)，這個(gè)線程會(huì)根據(jù)topic的隊(duì)列數(shù)量和當(dāng)前的消費(fèi)組的消費(fèi)者個(gè)數(shù)進(jìn)行負(fù)載均衡，每個(gè)隊(duì)列產(chǎn)生的請(qǐng)求都會(huì)放入到阻塞隊(duì)列中
然后有一個(gè)PullMessageService線程不斷的從該阻塞隊(duì)列中獲取請(qǐng)求，然后通過網(wǎng)絡(luò)請(qǐng)求broker，這樣算是實(shí)現(xiàn)了一種準(zhǔn)實(shí)時(shí)的拉取消息
源碼在PullMessageProcessor里面的processRequest方法，用來處理拉消息的請(qǐng)求，有消息返回，沒有消息就進(jìn)入了上述說的長(zhǎng)輪詢過程，這部分源碼我就不截了，大家感興趣的可以去研究研究
佛系求關(guān)注
Captain希望有一天能夠靠寫作養(yǎng)活自己，現(xiàn)在還在磨練，這個(gè)時(shí)間可能會(huì)持續(xù)很久，但是，請(qǐng)看我漂亮的堅(jiān)持
感謝大家能夠做我最初的讀者和傳播者，請(qǐng)大家相信，只要你給我一份愛，我終究會(huì)還你們一頁情的。
Captain會(huì)持續(xù)更新技術(shù)文章，和生活中的暴躁文章，歡迎大家關(guān)注【Java賊船】，成為船長(zhǎng)的學(xué)習(xí)小伙伴，和船長(zhǎng)一起乘千里風(fēng)、破萬里浪
哦對(duì)了，后續(xù)所有的遠(yuǎn)程文章都會(huì)更新到這里
https://github.com/DayuMM2021/Java
