一.前言
消息隊列是什麼，我就不在這裡給大家介紹了，寫這篇文章的目的就是為了和大家聊一聊為什麼使用消息隊列，最近聽幾個朋友說面試的時候簡歷上寫了MQ相關的技術點兒，結果面試的時候被面試官一陣連環炮提問給炸蒙了。連環炮式提問如下：
1.你們項目中是如何使用消息隊列？
2.你們為什麼要使用消息隊列？
3.消息隊列有什麼優缺點？
4.kafka、activemq、rabbitmq、rocketmq都有什麼區別？
5.你們項目是如何保證消息的高可用的？
6.如何保證消息不被重複消費？
7.如何保證消費的時候是冪等的？
8.如何保證消息的可靠性傳輸啊？
9.如何保證消息的順序性？
上面的連環炮式的提問你能回答上幾個呢？所以自己簡歷上寫了就儘量都準備充分，不要把模稜兩可的技術都寫上去，不要覺得自己項目用了這個技術就是優勢，如果自己沒有了解清楚，那把這些技術點寫入簡歷反而會成為自己的拖累，好了不多說了，我們就針對上面的提問來聊一聊消息隊列吧！
二.為什麼要使用消息隊列
這個問題一般我們應該從消息隊列的使用場景上來考慮，知道了消息隊列適用哪些場景，自然就知道為什麼要使用消息隊列了！
1.解耦
場景介紹：用戶下單後，訂單系統需要通知庫存系統，傳統的做法是，訂單系統調用庫存系統的接口
消息隊列應用場景-解耦
傳統模式的缺點在於，如果調用庫存系統失敗的話那麼用戶下單也會失敗，如果這種事情經常發生那麼該網站會損失很多用戶。
那麼如果引入消息隊列後是什麼樣呢？
消息隊列應用場景-解耦
訂單系統：用戶完成下單後，將訂單信息持久化到訂單庫，將相關信息寫入消息隊列，返回用戶下單成功
庫存系統：訂閱下單的消息，獲取到下單消息後，庫存系統根據下單消息後進行庫存操作
如果用戶在下單時庫存系統不能正常使用，也不會影響用戶下單操作，因為下單後，訂單系統將消息寫入消息隊列就不再關心後面的操作了，這樣就實現訂單系統和庫存系統的解耦！
2.異步
場景介紹：比如那我們的機票訂單結算系統來說，機票數據導入系統後需要和訂單數據進行匹配，傳統做法很簡單，就是一堆流程放在一起串行執行就可以了！
消息隊列應用場景-異步
用戶上傳機票文件耗時50ms，機票與訂單匹配需要450ms，那麼用戶需要等待500ms，如果需要匹配的機票和訂單量很大，那麼時間會更長，這樣對用戶就不太友好了，極端情況下，如果用戶上傳的機票文件就10幾條記錄，但是匹配卻很耗時，那麼用戶會瘋的，就上傳十幾條記錄你讓我等這麼長時間！
如果引入消息隊列會是什麼效果呢？
消息隊列應用場景-異步
效果是不是很明顯，用戶上傳文件很快就能得到響應，這樣對於用戶來說是非常友好，因為用戶當前的關注點就是文件導入，至於你後續的匹配對於當前用戶來說屬於非必要的業務，像這樣的需求我們就可以使用消息隊列進行異步處理！
3.削峰
削峰及流量削峰，削峰這種場景一般在互聯網企業遇到的比較多，對於內部項目很少能夠用到消息隊列這個功能。
場景介紹：秒殺或者趕上什麼週年紀念日搞活動
消息隊列應用場景-削峰
購票系統在平時能夠支持2K/s的併發請求，但是趕上五一或者國慶假期的時候購票需求激增，這時用戶有可能增加的5K/s的併發請求，大量請求湧入到後臺數據庫，可想而知數據的壓力有多，如果數據庫扛不住那麼系統就可能崩掉，想想都嚇人（不過我沒有遇到過，哈哈哈哈）
那麼消息隊列能幫我們做什麼呢？
消息隊列應該場景-削峰
引入消息隊列後，當大量請求湧入時，這些請求只是進入隊列中，我們的購票系統按照數據最大能夠承受的併發量從MQ中拉取請求進行處理即可
三.消息隊列有哪些優缺點
優點就不在重複了，上面的使用場景就是消息隊列的有點，那麼消息隊列有哪些缺點呢？
- 系統可用性降低了
系統引入的外部依賴越多，系統的可用性就越低
2.系統複雜性提高了
你以為只是簡單加個MQ進來就行了嗎？你怎麼保證消息沒有重複消費？怎麼處理消息丟失的情況？怎麼保證消息傳遞的順序性？後面一大堆問題呢，想想都頭疼
3.一致性問題
你想想用戶下單後，訂單系統將消息寫入隊列後直接返回成功了，用戶就真的以為這個購買是成功了，如果庫存系統最終處理消息失敗了怎麼辦，你這個數據就會出現不一致了
所以消息隊列實際是一種非常複雜的架構，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避掉。
四.kafka、activemq、rabbitmq、rocketmq都有什麼區別？
圖片來自於網絡如有侵權請聯繫作者刪除
至於如何保證隊列的高可用，如何防止重複消費等問題不是一兩句話就能說清楚，有的需要結合實際業務進行說明，我會在後續的文章中進行說明，今天就先寫到這裡，記得關注【不愛八阿哥】一個熱愛分享技術的碼農
