鏈接：https://www.zhihu.com/question/54152397/answer/657234090
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
一、什么是消息隊列？
消息隊列不知道大家看到這個詞的時候，會不會覺得它是一個比較高端的技術，反正我是覺得它好像是挺牛逼的。
消息隊列，一般我們會簡稱它為MQ(Message Queue)，嗯，就是很直白的簡寫。
我們先不管消息(Message)這個詞，來看看隊列(Queue)。這一看，隊列大家應該都熟悉吧。
隊列是一種 先進先出的數據結構。
在Java里邊，已經實現了不少的隊列了：
那為什么還需要消息隊列(MQ)這種中間件呢？？？其實這個問題，跟之前我學Redis的時候很像。Redis是一個以key-value形式存儲的內存數據庫，明明我們可以使用類似HashMap這種實現類就可以達到類似的效果了，那還為什么要Redis？《Redis合集》
- 到這里，大家可以先猜猜為什么要用消息隊列(MQ)這種中間件，下面會繼續補充。
消息隊列可以簡單理解為：把要傳輸的數據放在隊列中。
科普：
- 把數據放到消息隊列叫做生產者
- 從消息隊列里邊取數據叫做消費者
二、為什么要用消息隊列？
為什么要用消息隊列，也就是在問：用了消息隊列有什么好處。我們看看以下的場景
2.1 解耦
現在我有一個系統A，系統A可以產生一個userId
然后，現在有系統B和系統C都需要這個userId去做相關的操作
寫成偽代碼可能是這樣的：
public class SystemA { // 系統B和系統C的依賴 SystemB systemB = new SystemB(); SystemC systemC = new SystemC(); // 系統A獨有的數據userId private String userId = "Java3y"; public void doSomething() { // 系統B和系統C都需要拿着系統A的userId去操作其他的事 systemB.SystemBNeed2do(userId); systemC.SystemCNeed2do(userId); } }結構圖如下：
ok，一切平安無事度過了幾個天。
某一天，系統B的負責人告訴系統A的負責人，現在系統B的SystemBNeed2do(String userId)這個接口不再使用了，讓系統A別去調它了。
於是，系統A的負責人說"好的，那我就不調用你了。"，於是就把調用系統B接口的代碼給刪掉了：
public void doSomething() { // 系統A不再調用系統B的接口了 //systemB.SystemBNeed2do(userId); systemC.SystemCNeed2do(userId); }又過了幾天，系統D的負責人接了個需求，也需要用到系統A的userId，於是就跑去跟系統A的負責人說："老哥，我要用到你的userId，你調一下我的接口吧"
於是系統A說："沒問題的，這就搞"
然后，系統A的代碼如下：
public class SystemA { // 已經不再需要系統B的依賴了 // SystemB systemB = new SystemB(); // 系統C和系統D的依賴 SystemC systemC = new SystemC(); SystemD systemD = new SystemD(); // 系統A獨有的數據 private String userId = "Java3y"; public void doSomething() { // 已經不再需要系統B的依賴了 //systemB.SystemBNeed2do(userId); // 系統C和系統D都需要拿着系統A的userId去操作其他的事 systemC.SystemCNeed2do(userId); systemD.SystemDNeed2do(userId); } }時間飛逝：
- 又過了幾天，系統E的負責人過來了，告訴系統A，需要userId。
- 又過了幾天，系統B的負責人過來了，告訴系統A，還是重新掉那個接口吧。
- 又過了幾天，系統F的負責人過來了，告訴系統A，需要userId。
- …...
於是系統A的負責人，每天都被這給騷擾着，改來改去，改來改去.......
還有另外一個問題，調用系統C的時候，如果系統C掛了，系統A還得想辦法處理。如果調用系統D時，由於網絡延遲，請求超時了，那系統A是反饋fail還是重試？？
最后，系統A的負責人，覺得隔一段時間就改來改去，沒意思，於是就跑路了。
然后，公司招來一個大佬，大佬經過幾天熟悉，上來就說：將系統A的userId寫到消息隊列中，這樣系統A就不用經常改動了。為什么呢？下面我們來一起看看：
系統A將userId寫到消息隊列中，系統C和系統D從消息隊列中拿數據。這樣有什么好處？
- 系統A只負責把數據寫到隊列中，誰想要或不想要這個數據(消息)，系統A一點都不關心。
- 即便現在系統D不想要userId這個數據了，系統B又突然想要userId這個數據了，都跟系統A無關，系統A一點代碼都不用改。
- 系統D拿userId不再經過系統A，而是從消息隊列里邊拿。系統D即便掛了或者請求超時，都跟系統A無關，只跟消息隊列有關。
這樣一來，系統A與系統B、C、D都解耦了。
2.2 異步
我們再來看看下面這種情況：系統A還是直接調用系統B、C、D
代碼如下：
public class SystemA { SystemB systemB = new SystemB(); SystemC systemC = new SystemC(); SystemD systemD = new SystemD(); // 系統A獨有的數據 private String userId ; public void doOrder() { // 下訂單 userId = this.order(); // 如果下單成功，則安排其他系統做一些事 systemB.SystemBNeed2do(userId); systemC.SystemCNeed2do(userId); systemD.SystemDNeed2do(userId); } }假設系統A運算出userId具體的值需要50ms，調用系統B的接口需要300ms，調用系統C的接口需要300ms，調用系統D的接口需要300ms。那么這次請求就需要50+300+300+300=950ms
並且我們得知，系統A做的是主要的業務，而系統B、C、D是非主要的業務。比如系統A處理的是訂單下單，而系統B是訂單下單成功了，那發送一條短信告訴具體的用戶此訂單已成功，而系統C和系統D也是處理一些小事而已。
那么此時，為了提高用戶體驗和吞吐量，其實可以異步地調用系統B、C、D的接口。所以，我們可以弄成是這樣的：
系統A執行完了以后，將userId寫到消息隊列中，然后就直接返回了(至於其他的操作，則異步處理)。
- 本來整個請求需要用950ms(同步)
- 現在將調用其他系統接口異步化，只需要100ms(異步)
(例子可能舉得不太好，但我覺得說明到點子上就行了，見諒。)
2.3削峰/限流
我們再來一個場景，現在我們每個月要搞一次大促，大促期間的並發可能會很高的，比如每秒3000個請求。假設我們現在有兩台機器處理請求，並且每台機器只能每次處理1000個請求。
那多出來的1000個請求，可能就把我們整個系統給搞崩了...所以，有一種辦法，我們可以寫到消息隊列中：
系統B和系統C根據自己的能夠處理的請求數去消息隊列中拿數據，這樣即便有每秒有8000個請求，那只是把請求放在消息隊列中，去拿消息隊列的消息由系統自己去控制，這樣就不會把整個系統給搞崩。
三、使用消息隊列有什么問題？
經過我們上面的場景，我們已經可以發現，消息隊列能做的事其實還是蠻多的。
說到這里，我們先回到文章的開頭，"明明JDK已經有不少的隊列實現了，我們還需要消息隊列中間件呢？"其實很簡單，JDK實現的隊列種類雖然有很多種，但是都是簡單的內存隊列。為什么我說JDK是簡單的內存隊列呢？下面我們來看看要實現消息隊列(中間件)可能要考慮什么問題。
3.1高可用
無論是我們使用消息隊列來做解耦、異步還是削峰，消息隊列肯定不能是單機的。試着想一下，如果是單機的消息隊列，萬一這台機器掛了，那我們整個系統幾乎就是不可用了。
所以，當我們項目中使用消息隊列，都是得集群/分布式的。要做集群/分布式就必然希望該消息隊列能夠提供現成的支持，而不是自己寫代碼手動去實現。
3.2 數據丟失問題
我們將數據寫到消息隊列上，系統B和C還沒來得及取消息隊列的數據，就掛掉了。如果沒有做任何的措施，我們的數據就丟了。
學過Redis的都知道，Redis可以將數據持久化磁盤上，萬一Redis掛了，還能從磁盤從將數據恢復過來。同樣地，消息隊列中的數據也需要存在別的地方，這樣才盡可能減少數據的丟失。
那存在哪呢？
- 磁盤？
- 數據庫？
- Redis？
- 分布式文件系統？
同步存儲還是異步存儲？
3.3消費者怎么得到消息隊列的數據？
消費者怎么從消息隊列里邊得到數據？有兩種辦法：
- 生產者將數據放到消息隊列中，消息隊列有數據了，主動叫消費者去拿(俗稱push)
- 消費者不斷去輪訓消息隊列，看看有沒有新的數據，如果有就消費(俗稱pull)
3.4其他
除了這些，我們在使用的時候還得考慮各種的問題：
- 消息重復消費了怎么辦啊？
- 我想保證消息是絕對有順序的怎么做？
- ……..
雖然消息隊列給我們帶來了那么多的好處，但同時我們發現引入消息隊列也會提高系統的復雜性。市面上現在已經有不少消息隊列輪子了，每種消息隊列都有自己的特點，選取哪種MQ還得好好斟酌。
最后
本文主要講解了什么是消息隊列，消息隊列可以為我們帶來什么好處，以及一個消息隊列可能會涉及到哪些問題。希望給大家帶來一定的幫助。