面試官問我：什麼是消息隊列？什麼場景須要他？用了會出現什麼問題？

點贊再看，養成習慣

面試開始

一個風度翩翩，穿着格子襯衣的中年男子，拿着一個盡是劃痕的mac向你走來，看着錚亮的頭，心想着確定是尼瑪頂級架構師吧！可是咱們看過暖男敖丙的系列，腹有詩書氣自華，虛都不虛。

小夥子以前問了你這麼多Redis的知識，你不只對答如流，你還能把各自場景的解決方案，優缺點說得這麼流暢，說你是否是看過敖丙寫的《咱們一塊兒進大廠》系列呀？

驚！！！老師你怎麼知道的，我看了他的系列根本停不下來啊。

呵呵，Redis沒難住你，可是我問個新的技術棧我還怕難不住你？我問問你你項目中用過消息隊列麼？你爲啥用消息隊列？

噗此，這也叫問題？別人用了我能不用麼？別人用了我就用了唄，我就是爲了用而用。

你內心嘀咕就行了，千萬別說出來哈，說出來了沒拿到Offer別到時候就在那說，敖丙那個渣男教我說的！

面試官你好：咱們公司自己的業務體量很小，因此直接單機一把梭啥都能搞定了，可是後面業務體量不斷擴大，採用微服務的設計思想，分佈式的部署方式，因此拆分了不少的服務，隨着體量的增長以及業務場景愈來愈複雜了，不少場景單機的技術棧和中間件以及不夠用了，並且對系統的友好性也降低了，最後作了不少技術選型的工做，咱們決定引入消息隊列中間件。

哦？你說到業務場景愈來愈複雜，你那說一下你都在什麼場景用到了消息隊列？

嗯，我從三個方面去說一下我使用的場景吧。

Tip：這三個場景也是消息隊列的經典場景，你們基本上要爛熟於心那種，就是一說到消息隊列你腦子就要想到異步、削峯、解耦，條件反射那種。

異步：

咱們以前的場景裏面有不少步驟都是在一個流程裏面須要作完的，就好比說個人下單系統吧，原本咱們業務簡單，下單了付了錢就行了，流程就走完了。

可是後面來了個產品經理，搞了個優惠券系統，OK問題不大，流程裏面多100ms去扣減優惠券。

後來產品經理靈光一閃說咱們能夠搞個積分系統啊，也行吧，流程裏面多了200ms去增減積分。

再後來後來隔壁的產品老王說：下單成功後咱們要給用戶發短信，也將就吧，100ms去發個短信。

再後來。。。（敖丙你有完沒完！！！）

反正就流程有點像這樣 ↓

大家能夠看到這才加了三個，我能夠斬釘截鐵的告訴你真正的下單流程涉及的系統絕對在10個以上（主流電商），越大的越多。

這個鏈路這樣下去，時間長得一批，用戶發現我買個東西你特麼要花幾十秒，垃圾電商我不在你這裏買了，不過要是都像並夕夕這麼便宜，真香！

可是咱們公司沒有夕夕的那個經濟實力啊，那隻能優化系統了。

Tip：我以前在的電商老東家要求全部接口的Rt（ResponseTime響應時間）在200ms內，超出的所有優化，我如今所負責的系統QPS也是9W+就是抖動一下網絡集羣均可能炸鍋那種，RT基本上都要求在50ms之內。

你們感覺一下這個QPS。

嗯不錯，鏈路長了就慢了，那你怎麼解決的？

那鏈路長了就慢了，可是咱們發現上面的流程其實能夠同時作的呀，你支付成功後，我去校驗優惠券的同時我能夠去增減積分啊，還能夠同時發個短信啊。

那正常的流程咱們是沒辦法實現的呀，怎麼辦，異步。

你對比一下是否是發現，這樣子最多隻用100毫秒用戶知道下單成功了，至於短信你遲幾秒發給他他根本不在乎是吧。

小夥子我打斷你一下，你說了異步，那我用線程，線程池去作不是同樣的麼？

誒呀，面試官你不要急嘛，我後面還會說到的，騷等。

解耦：

既然面試官這麼問了，我就說一下爲啥咱們不能用線程去作，由於用線程去作，你是否是要寫代碼？

你一個訂單流程，你扣積分，扣優惠券，發短信，扣庫存。。。等等這麼多業務要調用這麼多的接口，每次加一個你要調用一個接口而後還要從新發布系統，寫一次兩次還好，寫多了你就說：老子不幹了！

並且真的所有都寫在一塊兒的話，不僅僅是耦合這一個問題，你出問題排查也麻煩，流程裏面隨便一個地方出問題搞很差會影響到其餘的點，小夥伴說我每一個流程都try catch不就好了，相信我別這麼作，這樣的代碼就像個定時炸彈💣，你不知道何時爆炸，平時不炸恰恰在你作活動的時候炸，你就領個P0故障收拾書包提早回家過年吧。

Tip：P0—PN 是互聯網大廠常常用來斷定事故等級的機制，P0是最高等級了。

可是你用了消息隊列，耦合這個問題就迎刃而解了呀。

哦，帥丙怎麼說？

且聽我娓娓道來：

你下單了，你就把你支付成功的消息告訴別的系統，他們收到了去處理就行了，你只用走完本身的流程，把本身的消息發出去，那後面要接入什麼系統簡單，直接訂閱你發送的支付成功消息，你支付成功了我監聽就行了。

那你的流程走完了，你不用管別人是否成功麼？好比你下單了積分沒加，優惠券沒扣怎麼辦？

問題是個好問題，可是不必考慮，業務系統自己就是本身的開發人員維護的，你積分扣失敗關我下單的什麼事情？你管好本身下單系統的就行了。

Tip：話是這麼說，可是這實際上是用了消息隊列的一個缺點，涉及到分佈式事務的知識點，我下面會提到。

削峯：

就拿我上一期寫的秒殺來講（暗示新同窗看我上一期），你平時流量很低，可是你要作秒殺活動00 ：00的時候流量瘋狂懟進來，你的服務器，Redis，MySQL各自的承受能力都不同，你直接所有流量照單全收確定有問題啊，直接就打掛了。

那怎麼辦？

簡單，把請求放到隊列裏面，而後至於每秒消費多少請求，就看本身的服務器處理能力，你能處理5000QPS你就消費這麼多，可能會比正常的慢一點，可是不至於打掛服務器，等流量高峯下去了，你的服務也就沒壓力了。

你看阿里雙十一12：00的時候這麼多流量瞬間涌進去，他有時候是否是會慢一點，可是人家沒掛啊，或者降級給你個友好的提示頁面，等高峯過去了又是一條好漢了。

爲了這個圖特地打高一臺服務的流量

聽你說了辣麼多，怎麼都是好處，那我問你使用了消息隊列有啥問題麼？

誒，看過前面我寫的文章的人才都知道，我常常說的就是，技術是把雙刃劍！

沒錯面試官，我使用他是由於他帶給咱們不少好處，可是使用以後問題也是接踵而至。

一樣的暖男我呀，也從三個點介紹他主要的缺點：

系統複雜性

原本蠻簡單的一個系統，我代碼隨便寫都沒事，如今你憑空接入一箇中間件在那，我是否是要考慮去維護他，並且使用的過程當中是否是要考慮各類問題，好比消息重複消費、消息丟失、消息的順序消費等等，反正用了以後就是賊煩。

我插一句嘴，上面的問題（重複消費、消息丟失、順序消費）你能分別介紹一下，而且說一下分別是怎麼解決的麼？

**不要！**我都說了敖丙下一章寫啥？

其實不是暖男我不想在這裏寫，這三個問題我想了下，通通都是MQ的重點問題，單獨拿一個出來就是一篇文章了，篇幅實在太長了，我會在下一章挨個介紹一遍的。

數據一致性

這個實際上是分佈式服務自己就存在的一個問題，不只僅是消息隊列的問題，可是放在這裏說是由於用了消息隊列這個問題會暴露得比較嚴重一點。

就像我開頭說的，你下單的服務本身保證本身的邏輯成功處理了，你成功發了消息，可是優惠券系統，積分系統等等這麼多系統，他們成功仍是失敗你就無論了？

我說了保證本身的業務數據對的就行了，其實仍是比較不負責任的一種說法，這樣就像個渣男，沒有格局，這樣呀你的路會越走越窄的。

全部的服務都成功才能算這一次下單是成功的，那怎麼才能保證數據一致性呢？

分佈式事務：把下單，優惠券，積分。。。都放在一個事務裏面同樣，要成功一塊兒成功，要失敗一塊兒失敗。

Tip:分佈式事務在互聯網公司裏面實在常見，我也不在這裏大篇幅介紹了，後面都會專門說的。

可用性

你搞個系統自己沒啥問題，你如今忽然接入一箇中間件在那放着，萬一掛了怎麼辦？我下個單MQ掛了，優惠券不扣了，積分不減了，這不是殺一個程序員能搞定的吧，感受得殺一片。

至於怎麼保證高可用，仍是那句話也不在這裏展開討論了，我後面同樣會寫，像寫Redis那樣寫出來的。

放心敖丙我不是渣男來的，我確定會對大家負責的。點贊！

看不出來啊，你有點東西呀，那我問一下你，大家是怎麼作技術選型的？

目前在市面上比較主流的消息隊列中間件主要有，Kafka、ActiveMQ、RabbitMQ、RocketMQ 等這幾種。

不過敖丙我想說的是，ActiveMQ和RabbitMQ這兩着由於吞吐量還有GitHub的社區活躍度的緣由，在各大互聯網公司都已經基本上絕跡了，業務體量通常的公司會是有在用的，可是愈來愈多的公司更青睞RocketMQ這樣的消息中間件了。

Kafka和RocketMQ一直在各自擅長的領域發光發亮，不過寫這篇文章的時候我問了螞蟻金服，字節跳動和美團的朋友，好像你們用的都有點不同，應該都是各自的中間件，可能作過修改，也多是自研的，大多沒有開源。

就像咱們公司就是是基於Kafka和RocketMQ二者的優勢自研的消息隊列中間件，吞吐量、可靠性、時效性等都很可觀。

咱們迴歸正題，我這裏用網上找的對比圖讓你們看看差距到底在哪裏：

你們其實一會兒就能看到差距了，就拿吞吐量來講，早期比較活躍的ActiveMQ 和RabbitMQ基本上不是後二者的對手了，在如今這樣大數據的年代吞吐量是真的很重要。

好比如今忽然爆發了一個超級熱點新聞，你的APP註冊用戶高達億數，你要想辦法第一時間把突發所有推送到每一個人手上，你沒有大吞吐量的消息隊列中間件用啥去推？

再說這些用戶大量涌進來看了你的新聞產生了一系列的附帶流量，你怎麼應對這些數據，不少場景離開消息隊列基本上難覺得繼。

就部署方式而言前二者也是大不如後面兩個自然分佈式架構的哥哥，都是高可用的分佈式架構，並且數據多個副本的數據也能作到0丟失。

咱們再聊一下RabbitMQ這個中間件其實還行，可是這玩意開發語言竟然是erlang，我敢說絕大部分工程師確定不會爲了一箇中間件去刻意學習一門語言的，開發維護成本你想都想不到，出個問題查都查半天。

至於RocketMQ（阿里開源的），git活躍度還能夠。基本上你push了本身的bug確認了有問題都有阿里大佬跟你試試解答並修復的，我我的推薦的也是這個，他的架構設計部分跟一樣是阿里開源的一個RPC框架是真的很像（Dubbo）多是由於師出同門的緣由吧。

Tip：Dubbo等我寫到RPC我會詳細介紹的。

Kafka我放到最後說，大家也應該知道了，壓軸的這是個大哥，大數據領域，公司的日誌採集，實時計算等場景，都離不開他的身影，他基本上算得上是世界範圍級別的消息隊列標杆了。

以上這些都只是一些我本身的我的意見，真正的選型仍是要去深刻研究的，否則那你公司一天UV就1000你告訴我你要去用Kafka我只能說你吃飽撐的。

記住，沒有最好的技術，只有最適合的技術，不要爲了用而用。

面試結束

嗯，小夥子不錯不錯，分析得很到位，那你記得下期來講一下消息隊列的高可用，重複消費、消息丟失、消息順序、分佈式事務等問題？

嗯嗯好的面試官，不過不肯定能不能一口氣說完，畢竟敖丙還沒開始寫，並且讀者還有可能白嫖，動力不必定夠。

嗯嗯這卻是個問題，不過啊在看的都是人才確定會給你點贊👍的！

我也這麼認爲。

總結

消息隊列的基礎知識我就先介紹這麼多，消息隊列在面試裏面基本上也是跟我前面寫的Redis同樣必問的。

面試的思路仍是同樣，要知其然，也要知其因此然，就是要知道爲啥用，用了有啥好處，有啥坑。

面試官不喜歡只知道用的，你只會用那哪天線上出問題怎麼辦？你難道在旁邊拜佛？

我是敖丙，一個在互聯網苟且偷生的工具人。

創做不易，不想被白嫖，各位的「三連」就是丙丙創做的最大動力，咱們下次見！