@
背景
程序員不懂點消息隊列的知識，怎么能證明你經歷過高並發系統的洗禮呢？看起來你的項目經歷比較單一和簡單嘛，面試官在心里應該有點看低你這位候選人了。就算你的項目里沒有用到，為了面試，你也得懂得一些消息隊列的基本原理及常見面試套路吧！
為什么使用消息隊列
你們的項目中有用到消息隊列嗎？為什么要使用消息隊列呢？
都說學以致用，不少候選人為了豐富自己的簡歷，會說自己精通XXX語言，項目中使用了Redis、MQ，知道已經使用，但如果為為何使用，就回答不出什么道道來。
這種情況下，面試官會以為，你只是一個普通干活的，平時可能只是CURD操作，修補bug，只是了解項目一些細枝末節，對於項目的整體設計架構，沒有自己的獨立思考，這樣人想達到中級工程師的水平也有點難啊，面試官會在心里對你的整體印象大大打折。
消息隊列的為什么使用必須結合項目的場景來說。項目場景有高並發，低延遲的需求，可能需要引入消息隊列，但引入消息隊列同時也會帶來一些問題，這是下一個需要考慮的問題。
消息隊列引入的主要原因有三個：解耦、異步和削峰。
-
解耦
一般公司的項目，在構建初期，一個服務里面就揉進去很多功能，敏捷開發嘛，快速迭代上線。舉個例子，S1系統產生的用戶數據源，可能會被S2、S3系統調用，后來又新增了S4系統，每次有系統的增刪，負責S1系統的開發人員都需要修改代碼，測試，上線，簡直煩不勝煩。
如果改為S1系統將數據打入消息隊列，哪個系統想要使用數據，直接消費消息隊列就ok了，世界真清凈。誰來接入我誰來負責，我只用管打入消息隊列是ok的就行。S1系統的開發人員可以悠閑喝茶知道別人怎么接入了！
-
異步
一般的服務，肯定會與存儲打交道，涉及到存儲一般有MySQL、MongoDB、Hbase或其他存儲。如下圖，假設，S1系統只是一些本地內存操作，耗時5ms，S2、S3寫庫為MySQL和Hbase，耗時分別是50ms和80ms，那系統的總耗時就是5+50+80=135ms。
雖然當前用戶訪問延時為135ms，速度也還可以了，但如果又增加了S4、S5系統呢，訪問延遲是逐漸增加的啊，到時候就會有人抱怨你的系統做的太爛了。如果改為消息隊列呢，S1將數據打入MQ，耗時5ms，總的系統延遲就是5+5=10ms，而且解耦了，再增加其他服務訪問延遲還是10ms，網站做的666啊，速度飛快。
-
削峰
任何公司的任何業務，都會有流量的高峰和低谷，每天00:00-6:00，系統訪問低谷，請求並發量可能就幾十個，一切很美好。但到了12:30-13:00，訪問流量竟然能達到10000/s，也是佩服公司的運營人員和公司的產品啊，產品訪問量大好啊，說明業務蒸蒸日上，但開發哥哥就沒這么好過了，並發量大，對數據持久層的訪問時個考驗。
假設當前S1系統訪問的MySQL還沒有做分庫分表的優化，那能抗住的QPS的上線就是2000左右。
高峰達到了10000/s啊，去做分庫分表，申請資源又有些浪費，因為在流量低谷時，只有幾十的qps，這時候使用消息隊列就比較合適了。這里只是舉簡單的例子，實際的系統處理起來肯定沒這么簡單了。延遲太多用戶可要被搶走了！
消息隊列有什么優缺點
假如你說了這些，面試官心里應該默默贊許，小伙子不錯嘛，優點基本都答出來了，那再問問你缺點。
萬事都有兩面性，有好就有壞。缺點大致有以下幾個：
-
可用性降低
服務中引入的依賴越多，引入的外部組件越多，維護的成本就越高，本來你只是S1調用S2、S3服務即可。引入了消息隊列，消息隊列打入失敗怎么辦？消息隊列掛了怎么辦？怎么保證消息隊列的穩定性？這些就需要后面再說了！
-
復雜度變高
消息重復消費怎么辦？消息丟失怎么辦？如果要求消費的消息有序又怎么搞？本來在一個S1里，這些問題都好解決，加了一個MQ，這下麻煩大了！
-
一致性
用戶請求S1返回成功，是真的成功了嗎？當然不是，這只是代表打入MQ成功了啊。但這是如果消費MQ的某個服務掛了怎么辦？你怎么監控，怎么處理數據一致性問題，真是搞的頭都大了。
引入消息隊列，有很多優點，但同時也帶來了很多缺點，但是為了提高系統的響應速度，高並發情況下還是要用的。
消息隊列的選型
缺點說的也頭頭是道嘛，面試官已經悄悄的在背后豎起了大拇指，小伙子不錯，有一定的架構思維，之道引入一個組件的優缺點。並不是只知其一不知其二，只知道干活的人！
那你們關於消息隊列是怎么選型的呢？
這就要從各個消息隊列的一些特性說起了。
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 單機吞吐量 | 萬級，比 RocketMQ、Kafka 低一個數量級 | 同 ActiveMQ | 10 萬級，支撐高吞吐 | 10 萬級，高吞吐，一般配合大數據類的系統來進行實時數據計算、日志采集等場景 |
| topic 數量對吞吐量的影響 | topic 可以達到幾百/幾千的級別，吞吐量會有較小幅度的下降，這是 RocketMQ 的一大優勢，在同等機器下，可以支撐大量的 topic | topic 從幾十到幾百個時候，吞吐量會大幅度下降，在同等機器下，Kafka 盡量保證 topic 數量不要過多，如果要支撐大規模的 topic，需要增加更多的機器資源 | ||
| 時效性 | ms 級 | 微秒級，這是 RabbitMQ 的一大特點，延遲最低 | ms 級 | 延遲在 ms 級以內 |
| 可用性 | 高，基於主從架構實現高可用 | 同 ActiveMQ | 非常高，分布式架構 | 非常高，分布式，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用 |
| 消息可靠性 | 有較低的概率丟失數據 | 基本不丟 | 經過參數優化配置，可以做到 0 丟失 | 同 RocketMQ |
| 功能支持 | MQ 領域的功能極其完備 | 基於 erlang 開發，並發能力很強，性能極好，延時很低 | MQ 功能較為完善，還是分布式的，擴展性好 | 功能較為簡單，主要支持簡單的 MQ 功能，在大數據領域的實時計算以及日志采集被大規模使用 |
對比之后：
一般來說，現在選擇RocketMQ，阿里出品，也已經捐獻給Apache，社區還算活躍。單機吞吐量及可用性也都可以滿足需求，后續分布式擴展功能支持也較好。
如果數據量非常大，偏向於大數據領域的實時計算及日志采集處理，且要求高可用，Kafka絕對是不二選擇！
重復消費你們是怎么解決的？
面試官又丟給你一個問題，重復消費，其實也就是消息冪等處理的問題？
首先什么情況會造成重復消費呢？
Kafka的consumer消費有個offset的概念，consumer消費數據之后，定期提交offset，如果提交過程中，系統無故宕機或重啟或網絡原因，提交失敗，那consumer就還會從上一個offset開始消費數據，這就是重復消費。
重復消費是消息隊列中非常常見的問題，只要保證冪等處理就可以，比如你可以用Redis或MySQL記錄下以處理消息的唯一id，碰到重復處理的消息，直接忽略即可！
小伙子，你知道的太多了，我都想讓你明天直接來上班了，但是不行，還是得讓下一位面試官來做做面試的樣子！😝！敬請期待下一期小灶！
程序員的小伙伴們，覺得自己孤單么，那就加入公眾號[程序員之道]，一起交流溝通，走出我們的程序員之道！
