一、什麼是消息隊列?
消息隊列不知道大家看到這個詞的時候,會不會覺得它是一個比較高端的技術,反正我是覺得它好像是挺牛逼的。
消息隊列,一般我們會簡稱它爲MQ(Message Queue),嗯,就是很直白的簡寫。
我們先不管消息(Message)這個詞,來看看隊列(Queue)。這一看,隊列大家應該都熟悉吧。
隊列是一種先進先出的數據結構。
在Java裏邊,已經實現了不少的隊列了:
那爲什麼還需要消息隊列(MQ)這種中間件呢???
-
到這裏,大家可以先猜猜爲什麼要用消息隊列(MQ)這種中間件,下面會繼續補充。
消息隊列可以簡單理解爲:把要傳輸的數據放在隊列中。
科普:
-
把數據放到消息隊列叫做生產者
-
從消息隊列裏邊取數據叫做消費者
二、爲什麼要用消息隊列?
爲什麼要用消息隊列,也就是在問:用了消息隊列有什麼好處。我們看看以下的場景
2.1 解耦
現在我有一個系統A,系統A可以產生一個userId
ok,一切平安無事度過了幾個天。
某一天,系統B的負責人告訴系統A的負責人,現在系統B的SystemBNeed2do(String userId)
這個接口不再使用了,讓系統A別去調它了。
於是,系統A的負責人說"好的,那我就不調用你了。",於是就把調用系統B接口的代碼給刪掉了:
時間飛逝:
-
又過了幾天,系統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
假設系統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還得好好斟酌。
最後
本文主要講解了什麼是消息隊列,消息隊列可以爲我們帶來什麼好處,以及一個消息隊列可能會涉及到哪些問題。希望給大家帶來一定的幫助。
(完)
這個文章不錯,轉載一下。
慚愧呀,很少使用到MQ這個東西。哎。