面試開始
一個風度翩翩，穿着格子襯衣的中年男子，拿着一個滿是劃痕的mac向你走來，看着铮亮的頭，心想着肯定是尼瑪頂級架構師吧！但是我們看過暖男敖丙的系列，腹有詩書氣自華，虛都不虛。
你為啥用消息隊列？
噗此，這也叫問題？别人用了我能不用麼？别人用了我就用了呗，我就是為了用而用。
你心裡嘀咕就好了，千萬别說出來哈，說出來了沒拿到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我隻能說你吃飽撐的。
記住，沒有最好的技術，隻有最适合的技術，不要為了用而用。
面試結束
嗯，小夥子不錯不錯，分析得很到位，那你記得下期來說一下消息隊列的高可用，重複消費、消息丢失、消息順序、分布式事務等問題？
嗯嗯好的面試官，不過不确定能不能一口氣說完，畢竟敖丙還沒開始寫，而且讀者還有可能白嫖，動力不一定夠。
嗯嗯這倒是個問題，不過啊在看的都是人才肯定會給你點贊 的！
我也這麼認為。