更新時間:2019-12-05 15:28:51 來源:動力節(jié)點 瀏覽2589次
就目前大環(huán)境來看,跳槽成功的難度比往年高很多??偨Y一下在面試大型互聯(lián)網公司的時候,很可能會被問到消息隊列的問題:
在何種場景下使用了消息中間件?
為什么要在系統(tǒng)里引入消息中間件?
如何實現(xiàn)冪等?
鏈式調用是我們在寫程序時候的一般流程,為了完成一個整體功能,會將其拆分成多個函數(shù)(或子模塊),比如模塊A調用模塊B,模塊B調用模塊C,模塊C調用模塊D。但在大型分布式應用中,系統(tǒng)間的RPC交互繁雜,一個功能背后要調用上百個接口并非不可能,這種架構有如下幾個劣勢:
1、 這些接口之間耦合比較嚴重,每新增一個下游功能,都要對上有的相關接口進行改造;舉個例子:假如系統(tǒng)A要發(fā)送數(shù)據(jù)給系統(tǒng)B和C,發(fā)送給每個系統(tǒng)的數(shù)據(jù)可能有差異,因此系統(tǒng)A對要發(fā)送給每個系統(tǒng)的數(shù)據(jù)進行了組裝,然后逐一發(fā)送;當代碼上線后,新增了一個需求:把數(shù)據(jù)也發(fā)送給D。此時就需要修改A系統(tǒng),讓他感知到D的存在,同時把數(shù)據(jù)處理好給D。在這個過程中你會看到,每接入一個下游系統(tǒng),都要對A系統(tǒng)進行代碼改造,開發(fā)聯(lián)調的效率很低。其整體架構如下圖:
2、 面對大流量并發(fā)時,容易被沖垮。每個接口模塊的吞吐能力是有限的,這個上限能力如果堤壩,當大流量(洪水)來臨時,容易被沖垮。
學好Java需要多少錢:鄭州Java培訓課程哪家好_鄭州Java培訓機構在哪里多少錢
3、 存在性能問題。RPC接口基本上是同步調用,整體的服務性能遵循“木桶理論”,即鏈路中最慢的那個接口。比如A調用B/C/D都是50ms,但此時B又調用了B1,花費2000ms,那么直接就拖累了整個服務性能。
什么是消息隊列 如何了解Java開發(fā)之消息隊列
根據(jù)上述的幾個問題,在設計系統(tǒng)時可以明確要達到的目標:
要做到系統(tǒng)解耦,當新的模塊接進來時,可以做到代碼改動最小;
設置流量緩沖池,可以讓后端系統(tǒng)按照自身吞吐能力進行消費,不被沖垮;
強弱依賴梳理,將非關鍵調用鏈路的操作異步化,提升整體系統(tǒng)的吞吐能力,比如上圖中A、B、C、D是讓用戶發(fā)起付款,然后返回付款成功提示的幾個關鍵流程,而B1是通知付款后通知商家發(fā)貨的模塊,那么實質上用戶對B1完成的時間容忍度比較大(比如幾秒之后),可以將其異步化。
在現(xiàn)在的系統(tǒng)視線中,MQ消息隊列是普遍使用的,可以完美的解決這些問題的利器。下圖是使用了MQ的簡單架構圖,可以看到MQ在最前端對流量進行蓄洪,下游的系統(tǒng)ABC只與MQ打交道,通過事先定義好的消息格式來解析。
引入MQ之后的系統(tǒng)架構、交互方式與最初的鏈式調用架構非常不同,雖然可以解決上文提到的問題,但也要充分理解其原理特性來避免其帶來的副作用,這里以消息隊列如何保證“消息的可靠投遞”為切入點,來看看MQ的實現(xiàn)方式。
一、Client如何將消息可靠投遞到MQ
1.Client發(fā)送消息給MQ
2.MQ將消息持久化后,發(fā)送Ack消息給Client,此處有可能因為網絡問題導致Ack消息無法發(fā)送到Client,那么Client在等待超時后,會重傳消息;
3.Client收到Ack消息后,認為消息已經投遞成功。
二、 MQ如何將消息可靠投遞到Client
1.MQ將消息push給Client(或Client來pull消息)
2.Client得到消息并做完業(yè)務邏輯
3.Client發(fā)送Ack消息給MQ,通知MQ刪除該消息,此處有可能因為網絡問題導致Ack失敗,那么Client會重復消息,這里就引出消費冪等的問題;
4.MQ將已消費的消息刪除
以上就是動力節(jié)點Java培訓機構小編介紹的“大型互聯(lián)網面試:Java開發(fā)消息隊列”的內容,希望對大家有幫助,如有疑問,請在線咨詢,有專業(yè)老師隨時為你服務。
相關推薦
最新最全java面試題及答案(初級到高級)