面試官問你什么是消息隊列？把這篇甩給他！

作者：Java3y 2019-04-15 14:40:46

開發(fā) 后端

消息隊列不知道大家看到這個詞的時候，會不會覺得它是一個比較高端的技術(shù)，反正我是覺得它好像是挺牛逼的。

[[262508]]

一、什么是消息隊列？

消息隊列不知道大家看到這個詞的時候，會不會覺得它是一個比較高端的技術(shù)，反正我是覺得它好像是挺牛逼的。

消息隊列，一般我們會簡稱它為MQ(Message Queue)，嗯，就是很直白的簡寫。

我們先不管消息(Message)這個詞，來看看隊列(Queue)。這一看，隊列大家應(yīng)該都熟悉吧。

隊列是一種先進(jìn)先出的數(shù)據(jù)結(jié)構(gòu)。

在Java里邊，已經(jīng)實(shí)現(xiàn)了不少的隊列了：

那為什么還需要消息隊列(MQ)這種中間件呢？？？

到這里，大家可以先猜猜為什么要用消息隊列(MQ)這種中間件，下面會繼續(xù)補(bǔ)充。

消息隊列可以簡單理解為：把要傳輸?shù)臄?shù)據(jù)放在隊列中。

圖片來源：https://www.cloudamqp.com/blog/2014-12-03-what-is-message-queuing.html

科普：

把數(shù)據(jù)放到消息隊列叫做生產(chǎn)者
從消息隊列里邊取數(shù)據(jù)叫做消費(fèi)者

二、為什么要用消息隊列？

為什么要用消息隊列，也就是在問：用了消息隊列有什么好處。我們看看以下的場景

2.1 解耦

現(xiàn)在我有一個系統(tǒng)A，系統(tǒng)A可以產(chǎn)生一個userId

然后，現(xiàn)在有系統(tǒng)B和系統(tǒng)C都需要這個userId去做相關(guān)的操作

寫成偽代碼可能是這樣的：

public class SystemA {  
    // 系統(tǒng)B和系統(tǒng)C的依賴  
    SystemB systemB = new SystemB();  
    SystemC systemC = new SystemC();  
    // 系統(tǒng)A獨(dú)有的數(shù)據(jù)userId  
    private String userId = "Java3y";  
    public void doSomething() {  
        // 系統(tǒng)B和系統(tǒng)C都需要拿著系統(tǒng)A的userId去操作其他的事  
        systemB.SystemBNeed2do(userId);  
        systemC.SystemCNeed2do(userId);  
    }  
}

結(jié)構(gòu)圖如下：

ok，一切平安無事度過了幾個天。

某一天，系統(tǒng)B的負(fù)責(zé)人告訴系統(tǒng)A的負(fù)責(zé)人，現(xiàn)在系統(tǒng)B的SystemBNeed2do(String userId)這個接口不再使用了，讓系統(tǒng)A別去調(diào)它了。

于是，系統(tǒng)A的負(fù)責(zé)人說"好的，那我就不調(diào)用你了。"，于是就把調(diào)用系統(tǒng)B接口的代碼給刪掉了：

public void doSomething() {  
  // 系統(tǒng)A不再調(diào)用系統(tǒng)B的接口了  
  //systemB.SystemBNeed2do(userId);  
  systemC.SystemCNeed2do(userId);  
}

又過了幾天，系統(tǒng)D的負(fù)責(zé)人接了個需求，也需要用到系統(tǒng)A的userId，于是就跑去跟系統(tǒng)A的負(fù)責(zé)人說："老哥，我要用到你的userId，你調(diào)一下我的接口吧"

于是系統(tǒng)A說："沒問題的，這就搞"

然后，系統(tǒng)A的代碼如下：

public class SystemA {  
    // 已經(jīng)不再需要系統(tǒng)B的依賴了  
    // SystemB systemB = new SystemB();  
    // 系統(tǒng)C和系統(tǒng)D的依賴  
    SystemC systemC = new SystemC();  
    SystemD systemD = new SystemD();  
    // 系統(tǒng)A獨(dú)有的數(shù)據(jù)  
    private String userId = "Java3y";  
    public void doSomething() {  
        // 已經(jīng)不再需要系統(tǒng)B的依賴了  
        //systemB.SystemBNeed2do(userId);  
        // 系統(tǒng)C和系統(tǒng)D都需要拿著系統(tǒng)A的userId去操作其他的事  
        systemC.SystemCNeed2do(userId);  
        systemD.SystemDNeed2do(userId);  
    }  
}

時間飛逝：

又過了幾天，系統(tǒng)E的負(fù)責(zé)人過來了，告訴系統(tǒng)A，需要userId。
又過了幾天，系統(tǒng)B的負(fù)責(zé)人過來了，告訴系統(tǒng)A，還是重新掉那個接口吧。
又過了幾天，系統(tǒng)F的負(fù)責(zé)人過來了，告訴系統(tǒng)A，需要userId。
……

于是系統(tǒng)A的負(fù)責(zé)人，每天都被這給騷擾著，改來改去，改來改去…….

還有另外一個問題，調(diào)用系統(tǒng)C的時候，如果系統(tǒng)C掛了，系統(tǒng)A還得想辦法處理。如果調(diào)用系統(tǒng)D時，由于網(wǎng)絡(luò)延遲，請求超時了，那系統(tǒng)A是反饋fail還是重試？？

***，系統(tǒng)A的負(fù)責(zé)人，覺得隔一段時間就改來改去，沒意思，于是就跑路了。

然后，公司招來一個大佬，大佬經(jīng)過幾天熟悉，上來就說：將系統(tǒng)A的userId寫到消息隊列中，這樣系統(tǒng)A就不用經(jīng)常改動了。為什么呢？下面我們來一起看看：

系統(tǒng)A將userId寫到消息隊列中，系統(tǒng)C和系統(tǒng)D從消息隊列中拿數(shù)據(jù)。這樣有什么好處？

系統(tǒng)A只負(fù)責(zé)把數(shù)據(jù)寫到隊列中，誰想要或不想要這個數(shù)據(jù)(消息)，系統(tǒng)A一點(diǎn)都不關(guān)心。
即便現(xiàn)在系統(tǒng)D不想要userId這個數(shù)據(jù)了，系統(tǒng)B又突然想要userId這個數(shù)據(jù)了，都跟系統(tǒng)A無關(guān)，系統(tǒng)A一點(diǎn)代碼都不用改。
系統(tǒng)D拿userId不再經(jīng)過系統(tǒng)A，而是從消息隊列里邊拿。系統(tǒng)D即便掛了或者請求超時，都跟系統(tǒng)A無關(guān)，只跟消息隊列有關(guān)。

這樣一來，系統(tǒng)A與系統(tǒng)B、C、D都解耦了。

2.2 異步

我們再來看看下面這種情況：系統(tǒng)A還是直接調(diào)用系統(tǒng)B、C、D

代碼如下：

public class SystemA {  
    SystemB systemB = new SystemB();  
    SystemC systemC = new SystemC();  
    SystemD systemD = new SystemD();  
    // 系統(tǒng)A獨(dú)有的數(shù)據(jù)  
    private String userId ;  
    public void doOrder() {  
        // 下訂單  
          userId = this.order();  
        // 如果下單成功，則安排其他系統(tǒng)做一些事    
        systemB.SystemBNeed2do(userId);  
        systemC.SystemCNeed2do(userId);  
        systemD.SystemDNeed2do(userId);  
    }  
}

假設(shè)系統(tǒng)A運(yùn)算出userId具體的值需要50ms，調(diào)用系統(tǒng)B的接口需要300ms，調(diào)用系統(tǒng)C的接口需要300ms，調(diào)用系統(tǒng)D的接口需要300ms。那么這次請求就需要50+300+300+300=950ms

并且我們得知，系統(tǒng)A做的是主要的業(yè)務(wù)，而系統(tǒng)B、C、D是非主要的業(yè)務(wù)。比如系統(tǒng)A處理的是訂單下單，而系統(tǒng)B是訂單下單成功了，那發(fā)送一條短信告訴具體的用戶此訂單已成功，而系統(tǒng)C和系統(tǒng)D也是處理一些小事而已。

那么此時，為了提高用戶體驗(yàn)和吞吐量，其實(shí)可以異步地調(diào)用系統(tǒng)B、C、D的接口。所以，我們可以弄成是這樣的：

系統(tǒng)A執(zhí)行完了以后，將userId寫到消息隊列中，然后就直接返回了(至于其他的操作，則異步處理)。

本來整個請求需要用950ms(同步)
現(xiàn)在將調(diào)用其他系統(tǒng)接口異步化，從請求到返回只需要100ms(異步)

(例子可能舉得不太好，但我覺得說明到點(diǎn)子上就行了，見諒。)

2.3削峰/限流

我們再來一個場景，現(xiàn)在我們每個月要搞一次大促，大促期間的并發(fā)可能會很高的，比如每秒3000個請求。假設(shè)我們現(xiàn)在有兩臺機(jī)器處理請求，并且每臺機(jī)器只能每次處理1000個請求。

那多出來的1000個請求，可能就把我們整個系統(tǒng)給搞崩了…所以，有一種辦法，我們可以寫到消息隊列中：

系統(tǒng)B和系統(tǒng)C根據(jù)自己的能夠處理的請求數(shù)去消息隊列中拿數(shù)據(jù)，這樣即便有每秒有8000個請求，那只是把請求放在消息隊列中，去拿消息隊列的消息由系統(tǒng)自己去控制，這樣就不會把整個系統(tǒng)給搞崩。

三、使用消息隊列有什么問題？

經(jīng)過我們上面的場景，我們已經(jīng)可以發(fā)現(xiàn)，消息隊列能做的事其實(shí)還是蠻多的。

說到這里，我們先回到文章的開頭，"明明JDK已經(jīng)有不少的隊列實(shí)現(xiàn)了，我們還需要消息隊列中間件呢？"其實(shí)很簡單，JDK實(shí)現(xiàn)的隊列種類雖然有很多種，但是都是簡單的內(nèi)存隊列。為什么我說JDK是簡單的內(nèi)存隊列呢？下面我們來看看要實(shí)現(xiàn)消息隊列(中間件)可能要考慮什么問題。

3.1高可用

無論是我們使用消息隊列來做解耦、異步還是削峰，消息隊列肯定不能是單機(jī)的。試著想一下，如果是單機(jī)的消息隊列，萬一這臺機(jī)器掛了，那我們整個系統(tǒng)幾乎就是不可用了。