互聯網面試開小竈系列之消息隊列(一)

背景

程序員不懂點消息隊列的知識，怎麼能證實你經歷太高併發系統的洗禮呢？看起來你的項目經歷比較單一和簡單嘛，面試官在內心應該有點看低你這位候選人了。就算你的項目裏沒有用到，爲了面試，你也得懂得一些消息隊列的基本原理及常見面試套路吧！

爲何使用消息隊列

大家的項目中有用到消息隊列嗎？爲何要使用消息隊列呢？

都說學以至用，很多候選人爲了豐富本身的簡歷，會說本身精通XXX語言，項目中使用了Redis、MQ，知道已經使用，但若是爲爲什麼使用，就回答不出什麼道道來。

這種狀況下，面試官會覺得，你只是一個普通幹活的，平時可能只是CURD操做，修補bug，只是瞭解項目一些細枝末節，對於項目的總體設計架構，沒有本身的獨立思考，這樣人想達到中級工程師的水平也有點難啊，面試官會在內心對你的總體印象大大打折。

消息隊列的爲何使用必須結合項目的場景來講。項目場景有高併發，低延遲的需求，可能須要引入消息隊列，但引入消息隊列同時也會帶來一些問題，這是下一個須要考慮的問題。

消息隊列引入的主要緣由有三個：解耦、異步和削峯。

1. 解耦

   通常公司的項目，在構建初期，一個服務裏面就揉進去不少功能，敏捷開發嘛，快速迭代上線。舉個例子，S1系統產生的用戶數據源，可能會被S二、S3系統調用，後來又新增了S4系統，每次有系統的增刪，負責S1系統的開發人員都須要修改代碼，測試，上線，簡直煩不勝煩。

   

   若是改成S1系統將數據打入消息隊列，哪一個系統想要使用數據，直接消費消息隊列就ok了，世界真清淨。誰來接入我誰來負責，我只用管打入消息隊列是ok的就行。S1系統的開發人員能夠清閒喝茶知作別人怎麼接入了！

2. 異步

   通常的服務，確定會與存儲打交道，涉及到存儲通常有MySQL、MongoDB、Hbase或其餘存儲。以下圖，假設，S1系統只是一些本地內存操做，耗時5ms，S二、S3寫庫爲MySQL和Hbase，耗時分別是50ms和80ms，那系統的總耗時就是5+50+80=135ms。

   

   雖然當前用戶訪問延時爲135ms，速度也還能夠了，但若是又增長了S四、S5系統呢，訪問延遲是逐漸增長的啊，到時候就會有人抱怨你的系統作的太爛了。若是改成消息隊列呢，S1將數據打入MQ，耗時5ms，總的系統延遲就是5+5=10ms，並且解耦了，再增長其餘服務訪問延遲仍是10ms，網站作的666啊，速度飛快。

   

3. 削峯

任何公司的任何業務，都會有流量的高峯和低谷，天天00:00-6:00，系統訪問低谷，請求併發量可能就幾十個，一切很美好。但到了12:30-13:00，訪問流量居然能達到10000/s，也是佩服公司的運營人員和公司的產品啊，產品訪問量大好啊，說明業務蒸蒸日上，但開發哥哥就沒這麼好過了，併發量大，對數據持久層的訪問時個考驗。

假設當前S1系統訪問的MySQL尚未作分庫分表的優化，那能抗住的QPS的上線就是2000左右。

高峯達到了10000/s啊，去作分庫分表，申請資源又有些浪費，由於在流量低谷時，只有幾十的qps，這時候使用消息隊列就比較合適了。這裏只是舉簡單的例子，實際的系統處理起來確定沒這麼簡單了。延遲太多用戶可要被搶走了！

消息隊列有什麼優缺點

假如你說了這些，面試官內心應該默默讚許，小夥子不錯嘛，優勢基本都答出來了，那再問問你缺點。

萬事都有兩面性，有好就有壞。缺點大體有如下幾個：

• 可用性下降

  服務中引入的依賴越多，引入的外部組件越多，維護的成本就越高，原本你只是S1調用S二、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，碰到重複處理的消息，直接忽略便可！

小夥子，你知道的太多了，我都想讓你明天直接來上班了，可是不行，仍是得讓下一位面試官來作作面試的樣子！😝！敬請期待下一期小竈！

程序員的小夥伴們，以爲本身孤單麼，那就加入公衆號[程序員之道]，一塊兒交流溝通，走出咱們的程序員之道！