面試開始
小伙子之前問了你這么多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我只能說你吃飽撐的。
記住，沒有最好的技術，只有最適合的技術，不要為了用而用。
面試結束
嗯，小伙子不錯不錯，分析得很到位，那你記得下期來說一下消息隊列的高可用，重復消費、消息丟失、消息順序、分布式事務等問題？
嗯嗯好的面試官，不過不確定能不能一口氣說完，畢竟敖丙還沒開始寫，而且讀者還有可能白嫖，動力不一定夠。
嗯嗯這倒是個問題，不過啊在看的都是人才肯定會給你點贊的！
我也這么認為。
鳴謝
之前的文章寫了很多人加我，然后有個人才說是他螞蟻金服的Leader推薦的我，我突然意識到我文章的受眾好像慢慢變廣了，之后不嚴謹的點要杜絕掉。
所以之后我的文章經常會有大廠的小伙伴Review，也希望幫助我更好的監督自己的文章吧。
這次是 某阿里系電商跟我一起做過活動小組的 佩恩幫我Review的文章，感謝！
關鍵詞：
責任編輯：Rex_20
