面試官問我：什么是消息隊(duì)列？什么場景需要他？用了會(huì)出現(xiàn)什么問題？
面試開始
一個(gè)風(fēng)度翩翩，穿著格子襯衣的中年男子，拿著一個(gè)滿是劃痕的mac向你走來，看著錚亮的頭，心想著肯定是尼瑪頂級(jí)架構(gòu)師吧！但是我們看過暖男敖丙的系列，腹有詩書氣自華，虛都不虛。
小伙子之前問了你這么多Redis的知識(shí)，你不僅對答如流，你還能把各自場景的解決方案，優(yōu)缺點(diǎn)說得這么流暢，說你是不是看過敖丙寫的《我們一起進(jìn)大廠》系列呀？
驚?。?！老師你怎么知道的，我看了他的系列根本停不下來啊。
呵呵，Redis沒難住你，但是我問個(gè)新的技術(shù)棧我還怕難不住你？我問問你你項(xiàng)目中用過消息隊(duì)列么？你為啥用消息隊(duì)列？
噗此，這也叫問題？別人用了我能不用么？別人用了我就用了唄，我就是為了用而用。
你心里嘀咕就好了，千萬別說出來哈，說出來了沒拿到Offer別到時(shí)候就在那說，敖丙那個(gè)渣男教我說的！
面試官你好：我們公司本身的業(yè)務(wù)體量很小，所以直接單機(jī)一把梭啥都能搞定了，但是后面業(yè)務(wù)體量不斷擴(kuò)大，采用微服務(wù)的設(shè)計(jì)思想，分布式的部署方式，所以拆分了很多的服務(wù)，隨著體量的增加以及業(yè)務(wù)場景越來越復(fù)雜了，很多場景單機(jī)的技術(shù)棧和中間件以及不夠用了，而且對系統(tǒng)的友好性也下降了，最后做了很多技術(shù)選型的工作，我們決定引入消息隊(duì)列中間件。
哦？你說到業(yè)務(wù)場景越來越復(fù)雜，你那說一下你都在什么場景用到了消息隊(duì)列？
嗯，我從三個(gè)方面去說一下我使用的場景吧。
Tip：這三個(gè)場景也是消息隊(duì)列的經(jīng)典場景，大家基本上要爛熟于心那種，就是一說到消息隊(duì)列你腦子就要想到異步、削峰、解耦，條件反射那種。
異步：
我們之前的場景里面有很多步驟都是在一個(gè)流程里面需要做完的，就比如說我的下單系統(tǒng)吧，本來我們業(yè)務(wù)簡單，下單了付了錢就好了，流程就走完了。
但是后面來了個(gè)產(chǎn)品經(jīng)理，搞了個(gè)優(yōu)惠券系統(tǒng)，OK問題不大，流程里面多100ms去扣減優(yōu)惠券。
后來產(chǎn)品經(jīng)理靈光一閃說我們可以搞個(gè)積分系統(tǒng)啊，也行吧，流程里面多了200ms去增減積分。
再后來后來隔壁的產(chǎn)品老王說：下單成功后我們要給用戶發(fā)短信，也將就吧，100ms去發(fā)個(gè)短信。
再后來。。。（敖丙你有完沒完?。。。?/p>
反正就流程有點(diǎn)像這樣 ↓
你們可以看到這才加了三個(gè)，我可以斬釘截鐵的告訴你真正的下單流程涉及的系統(tǒng)絕對在10個(gè)以上（主流電商），越大的越多。
這個(gè)鏈路這樣下去，時(shí)間長得一批，用戶發(fā)現(xiàn)我買個(gè)東西你特么要花幾十秒，垃圾電商我不在你這里買了，不過要是都像并夕夕這么便宜，真香！
但是我們公司沒有夕夕的那個(gè)經(jīng)濟(jì)實(shí)力啊，那只能優(yōu)化系統(tǒng)了。
Tip：我之前在的電商老東家要求所有接口的Rt（ResponseTime響應(yīng)時(shí)間）在200ms內(nèi)，超出的全部優(yōu)化，我現(xiàn)在所負(fù)責(zé)的系統(tǒng)QPS也是9W+就是抖動(dòng)一下網(wǎng)絡(luò)集群都可能炸鍋那種，RT基本上都要求在50ms以內(nèi)。
大家感受一下這個(gè)QPS。
嗯不錯(cuò)，鏈路長了就慢了，那你怎么解決的？
那鏈路長了就慢了，但是我們發(fā)現(xiàn)上面的流程其實(shí)可以同時(shí)做的呀，你支付成功后，我去校驗(yàn)優(yōu)惠券的同時(shí)我可以去增減積分啊，還可以同時(shí)發(fā)個(gè)短信啊。
那正常的流程我們是沒辦法實(shí)現(xiàn)的呀，怎么辦，異步。
你對比一下是不是發(fā)現(xiàn)，這樣子最多只用100毫秒用戶知道下單成功了，至于短信你遲幾秒發(fā)給他他根本不在意是吧。
小伙子我打斷你一下，你說了異步，那我用線程，線程池去做不是一樣的么？
誒呀，面試官你不要急嘛，我后面還會(huì)說到的，騷等。
解耦：
既然面試官這么問了，我就說一下為啥我們不能用線程去做，因?yàn)橛镁€程去做，你是不是要寫代碼？
你一個(gè)訂單流程，你扣積分，扣優(yōu)惠券，發(fā)短信，扣庫存。。。等等這么多業(yè)務(wù)要調(diào)用這么多的接口，每次加一個(gè)你要調(diào)用一個(gè)接口然后還要重新發(fā)布系統(tǒng)，寫一次兩次還好，寫多了你就說：老子不干了！
而且真的全部都寫在一起的話，不單單是耦合這一個(gè)問題，你出問題排查也麻煩，流程里面隨便一個(gè)地方出問題搞不好會(huì)影響到其他的點(diǎn)，小伙伴說我每個(gè)流程都try catch不就行了，相信我別這么做，這樣的代碼就像個(gè)定時(shí)炸彈💣，你不知道什么時(shí)候爆炸，平時(shí)不炸偏偏在你做活動(dòng)的時(shí)候炸，你就領(lǐng)個(gè)P0故障收拾書包提前回家過年吧。
Tip：P0—PN 是互聯(lián)網(wǎng)大廠經(jīng)常用來判定事故等級(jí)的機(jī)制，P0是最高等級(jí)了。
但是你用了消息隊(duì)列，耦合這個(gè)問題就迎刃而解了呀。
哦，帥丙怎么說？
且聽我娓娓道來：
你下單了，你就把你支付成功的消息告訴別的系統(tǒng)，他們收到了去處理就好了，你只用走完自己的流程，把自己的消息發(fā)出去，那后面要接入什么系統(tǒng)簡單，直接訂閱你發(fā)送的支付成功消息，你支付成功了我監(jiān)聽就好了。
那你的流程走完了，你不用管別人是否成功么？比如你下單了積分沒加，優(yōu)惠券沒扣怎么辦？
問題是個(gè)好問題，但是沒必要考慮，業(yè)務(wù)系統(tǒng)本身就是自己的開發(fā)人員維護(hù)的，你積分扣失敗關(guān)我下單的什么事情？你管好自己下單系統(tǒng)的就好了。
Tip：話是這么說，但是這其實(shí)是用了消息隊(duì)列的一個(gè)缺點(diǎn)，涉及到分布式事務(wù)的知識(shí)點(diǎn)，我下面會(huì)提到。
削峰：
就拿我上一期寫的秒殺來說（暗示新同學(xué)看我上一期），你平時(shí)流量很低，但是你要做秒殺活動(dòng)00 ：00的時(shí)候流量瘋狂懟進(jìn)來，你的服務(wù)器，Redis，MySQL各自的承受能力都不一樣，你直接全部流量照單全收肯定有問題啊，直接就打掛了。
那怎么辦？
簡單，把請求放到隊(duì)列里面，然后至于每秒消費(fèi)多少請求，就看自己的服務(wù)器處理能力，你能處理5000QPS你就消費(fèi)這么多，可能會(huì)比正常的慢一點(diǎn)，但是不至于打掛服務(wù)器，等流量高峰下去了，你的服務(wù)也就沒壓力了。
你看阿里雙十一12：00的時(shí)候這么多流量瞬間涌進(jìn)去，他有時(shí)候是不是會(huì)慢一點(diǎn)，但是人家沒掛啊，或者降級(jí)給你個(gè)友好的提示頁面，等高峰過去了又是一條好漢了。
為了這個(gè)圖特意打高一臺(tái)服務(wù)的流量
為了這個(gè)圖特意打高一臺(tái)服務(wù)的流量
聽你說了辣么多，怎么都是好處，那我問你使用了消息隊(duì)列有啥問題么？
誒，看過前面我寫的文章的人才都知道，我經(jīng)常說的就是，技術(shù)是把雙刃劍！
沒錯(cuò)面試官，我使用他是因?yàn)樗麕Ыo我們很多好處，但是使用之后問題也是接踵而至。
同樣的暖男我呀，也從三個(gè)點(diǎn)介紹他主要的缺點(diǎn)：
系統(tǒng)復(fù)雜性
本來蠻簡單的一個(gè)系統(tǒng)，我代碼隨便寫都沒事，現(xiàn)在你憑空接入一個(gè)中間件在那，我是不是要考慮去維護(hù)他，而且使用的過程中是不是要考慮各種問題，比如消息重復(fù)消費(fèi)、消息丟失、消息的順序消費(fèi)等等，反正用了之后就是賊煩。
我插一句嘴，上面的問題（重復(fù)消費(fèi)、消息丟失、順序消費(fèi)）你能分別介紹一下，并且說一下分別是怎么解決的么？
**不要！**我都說了敖丙下一章寫啥？
其實(shí)不是暖男我不想在這里寫，這三個(gè)問題我想了下，統(tǒng)統(tǒng)都是MQ的重點(diǎn)問題，單獨(dú)拿一個(gè)出來就是一篇文章了，篇幅實(shí)在太長了，我會(huì)在下一章挨個(gè)介紹一遍的。
數(shù)據(jù)一致性
這個(gè)其實(shí)是分布式服務(wù)本身就存在的一個(gè)問題，不僅僅是消息隊(duì)列的問題，但是放在這里說是因?yàn)橛昧讼㈥?duì)列這個(gè)問題會(huì)暴露得比較嚴(yán)重一點(diǎn)。
就像我開頭說的，你下單的服務(wù)自己保證自己的邏輯成功處理了，你成功發(fā)了消息，但是優(yōu)惠券系統(tǒng)，積分系統(tǒng)等等這么多系統(tǒng)，他們成功還是失敗你就不管了？
我說了保證自己的業(yè)務(wù)數(shù)據(jù)對的就好了，其實(shí)還是比較不負(fù)責(zé)任的一種說法，這樣就像個(gè)渣男，沒有格局，這樣呀你的路會(huì)越走越窄的。
所有的服務(wù)都成功才能算這一次下單是成功的，那怎么才能保證數(shù)據(jù)一致性呢？
分布式事務(wù)：把下單，優(yōu)惠券，積分。。。都放在一個(gè)事務(wù)里面一樣，要成功一起成功，要失敗一起失敗。
Tip:分布式事務(wù)在互聯(lián)網(wǎng)公司里面實(shí)在常見，我也不在這里大篇幅介紹了，后面都會(huì)專門說的。
可用性
你搞個(gè)系統(tǒng)本身沒啥問題，你現(xiàn)在突然接入一個(gè)中間件在那放著，萬一掛了怎么辦？我下個(gè)單MQ掛了，優(yōu)惠券不扣了，積分不減了，這不是殺一個(gè)程序員能搞定的吧，感覺得殺一片。
至于怎么保證高可用，還是那句話也不在這里展開討論了，我后面一樣會(huì)寫，像寫Redis那樣寫出來的。
放心敖丙我不是渣男來的，我肯定會(huì)對你們負(fù)責(zé)的。點(diǎn)贊！
看不出來啊，你有點(diǎn)東西呀，那我問一下你，你們是怎么做技術(shù)選型的？
目前在市面上比較主流的消息隊(duì)列中間件主要有，Kafka、ActiveMQ、RabbitMQ、rocketMQ 等這幾種。
不過敖丙我想說的是，ActiveMQ和RabbitMQ這兩著因?yàn)橥掏铝窟€有GitHub的社區(qū)活躍度的原因，在各大互聯(lián)網(wǎng)公司都已經(jīng)基本上絕跡了，業(yè)務(wù)體量一般的公司會(huì)是有在用的，但是越來越多的公司更青睞rocketMQ這樣的消息中間件了。
Kafka和rocketMQ一直在各自擅長的領(lǐng)域發(fā)光發(fā)亮，不過寫這篇文章的時(shí)候我問了螞蟻金服，字節(jié)跳動(dòng)和美團(tuán)的朋友，好像大家用的都有點(diǎn)不一樣，應(yīng)該都是各自的中間件，可能做過修改，也可能是自研的，大多沒有開源。
就像我們公司就是是基于Kafka和rocketMQ兩者的優(yōu)點(diǎn)自研的消息隊(duì)列中間件，吞吐量、可靠性、時(shí)效性等都很可觀。
我們回歸正題，我這里用網(wǎng)上找的對比圖讓大家看看差距到底在哪里：
大家其實(shí)一下子就能看到差距了，就拿吞吐量來說，早期比較活躍的ActiveMQ 和RabbitMQ基本上不是后兩者的對手了，在現(xiàn)在這樣大數(shù)據(jù)的年代吞吐量是真的很重要。
比如現(xiàn)在突然爆發(fā)了一個(gè)超級(jí)熱點(diǎn)新聞，你的APP注冊用戶高達(dá)億數(shù)，你要想辦法第一時(shí)間把突發(fā)全部推送到每個(gè)人手上，你沒有大吞吐量的消息隊(duì)列中間件用啥去推？
再說這些用戶大量涌進(jìn)來看了你的新聞產(chǎn)生了一系列的附帶流量，你怎么應(yīng)對這些數(shù)據(jù)，很多場景離開消息隊(duì)列基本上難以為繼。
就部署方式而言前兩者也是大不如后面兩個(gè)天然分布式架構(gòu)的哥哥，都是高可用的分布式架構(gòu)，而且數(shù)據(jù)多個(gè)副本的數(shù)據(jù)也能做到0丟失。
我們再聊一下RabbitMQ這個(gè)中間件其實(shí)還行，但是這玩意開發(fā)語言居然是erlang，我敢說絕大部分工程師肯定不會(huì)為了一個(gè)中間件去刻意學(xué)習(xí)一門語言的，開發(fā)維護(hù)成本你想都想不到，出個(gè)問題查都查半天。
至于rocketMQ（阿里開源的），git活躍度還可以。基本上你push了自己的bug確認(rèn)了有問題都有阿里大佬跟你試試解答并修復(fù)的，我個(gè)人推薦的也是這個(gè)，他的架構(gòu)設(shè)計(jì)部分跟同樣是阿里開源的一個(gè)RPC框架是真的很像（Dubbo）可能是因?yàn)閹煶鐾T的原因吧。
Tip：Dubbo等我寫到RPC我會(huì)詳細(xì)介紹的。
Kafka我放到最后說，你們也應(yīng)該知道了，壓軸的這是個(gè)大哥，大數(shù)據(jù)領(lǐng)域，公司的日志采集，實(shí)時(shí)計(jì)算等場景，都離不開他的身影，他基本上算得上是世界范圍級(jí)別的消息隊(duì)列標(biāo)桿了。
以上這些都只是一些我自己的個(gè)人意見，真正的選型還是要去深入研究的，不然那你公司一天UV就1000你告訴我你要去用Kafka我只能說你吃飽撐的。
記住，沒有最好的技術(shù)，只有最適合的技術(shù)，不要為了用而用。
面試結(jié)束
嗯，小伙子不錯(cuò)不錯(cuò)，分析得很到位，那你記得下期來說一下消息隊(duì)列的高可用，重復(fù)消費(fèi)、消息丟失、消息順序、分布式事務(wù)等問題？
嗯嗯好的面試官，不過不確定能不能一口氣說完，畢竟敖丙還沒開始寫，而且讀者還有可能白嫖，動(dòng)力不一定夠。
嗯嗯這倒是個(gè)問題，不過啊在看的都是人才肯定會(huì)給你點(diǎn)贊👍的！
我也這么認(rèn)為。
總結(jié)
消息隊(duì)列的基礎(chǔ)知識(shí)我就先介紹這么多，消息隊(duì)列在面試?yán)锩婊旧弦彩歉仪懊鎸懙腞edis一樣必問的。
面試的思路還是一樣，要知其然，也要知其所以然，就是要知道為啥用，用了有啥好處，有啥坑。
面試官不喜歡只知道用的，你只會(huì)用那哪天線上出問題怎么辦？你難道在旁邊拜佛？
我是敖丙，一個(gè)在互聯(lián)網(wǎng)茍且偷生的工具人。
