消息隊列使用場景及優(yōu)缺點

消息隊列

在分布式系統(tǒng)中,經(jīng)常使用到的一個中間件就是消息隊列,所以為什么要使用消息隊列,消息隊列使用有哪些優(yōu)缺點?

1.為什么要使用消息隊列?

事實上,回答這個問題也就是在考慮消息隊列的使用場景,使用消息隊列能解決些什么問題:

1.1.解耦

有這么一個場景,在微服務系統(tǒng)中,當A系統(tǒng)產(chǎn)生新數(shù)據(jù)后需要將數(shù)據(jù)發(fā)送給BCD系統(tǒng)。如果此時E系統(tǒng)也需要,那么A系統(tǒng)需要適配;如果B系統(tǒng)不再需要了,那么A系統(tǒng)也必須要適配;如果有些系統(tǒng)掛了,A系統(tǒng)需不需要重發(fā)等。所以A系統(tǒng)與下游系統(tǒng)耦合性很高。如果在它們之間引入MQ(消息隊列),會帶來哪些優(yōu)化。

解耦1.png

引入MQ之后,A系統(tǒng)產(chǎn)生新數(shù)據(jù)之后,直接發(fā)送到MQ中,哪些系統(tǒng)需要數(shù)據(jù),自己去MQ中消費,如果不需要了,可以取消對MQ的消費操作,這樣,A系統(tǒng)不需要再去考慮給誰發(fā)送數(shù)據(jù)問題,依賴MQ的特性,也不需要關(guān)注下游服務是否消費成功,重發(fā)數(shù)據(jù)等問題。

解耦2.png

總結(jié):通過中間層引入MQ,發(fā)布訂閱模式,將A系統(tǒng)與下游服務進行業(yè)務解耦。

1.2.異步

再看另一個場景,

下圖(左),當瀏覽器發(fā)送一個請求到A系統(tǒng)時,這個請求業(yè)務的完成需要依賴于BCD系統(tǒng),比如A系統(tǒng)為訂單模塊,訂單生成之后需要完成B系統(tǒng)的積分等流程,比如A系統(tǒng)業(yè)務完成需要3ms,BCD業(yè)務完成個需要300ms,所以整個流程需要3+450+500+450=1403ms,這對于一般互聯(lián)網(wǎng)來說,時長有點不太友好,基本要求在一個請求完成在200ms內(nèi)

下圖(右),引入MQ之后,A系統(tǒng)不在需要等待BCD的同步操作,而是將預期操作同步下發(fā)到三個隊列中,然后直接返回給瀏覽器成功,加入這過程耗時5ms,那么總時長為3+5=8ms,非??欤W(wǎng)站做的非常nice!

異步.png

總結(jié):通過引入MQ實現(xiàn)預期的異步操作,但是會面臨最終一致性問題

1.3.削峰

下圖(左),假如A系統(tǒng)每天到 12:00 ~ 13:00 ,每秒并發(fā)請求數(shù)量突然會暴增到 5k+ 條。系統(tǒng)基于 MySQL 做數(shù)據(jù)處理,每秒并發(fā)大概2k,大量的請求涌入 MySQL,可能就直接把 MySQL 給打死了,導致系統(tǒng)崩潰,但是高峰期一過,其他時間可能也就 1w 的用戶同時在網(wǎng)站上操作,每秒中的請求數(shù)量可能也就 50 個請求,對整個系統(tǒng)幾乎沒有任何的壓力。

下圖(右),引入MQ之后,每秒 5k 個請求寫入 MQ,A 系統(tǒng)每秒鐘最多處理 2k 個請求,不要超過自己每秒能處理的最大請求數(shù)量即可,A 系統(tǒng)從 MQ 中慢慢拉取請求,這樣哪怕是高峰期的時候,A 系統(tǒng)也絕對不會掛掉。但是MQ 每秒鐘 5k 個請求進來,就 2k 個請求出去,會導致在高峰期(1 個小時),可能有幾十萬甚至幾百萬的請求積壓在 MQ 中。這個短暫的高峰期積壓是 ok 的,因為高峰期過了之后,每秒鐘就 50 個請求進 MQ,但是 A 系統(tǒng)依然會按照每秒 2k 個請求的速度在處理。所以說,只要高峰期一過,A 系統(tǒng)就會快速將積壓的消息給解決掉。

削峰.png

總結(jié):通過引入MQ存儲短時間大量的涌入的數(shù)據(jù),給后端系統(tǒng)帶來緩沖時間,但是會導致請求積壓。

2.優(yōu)缺點

2.1.優(yōu)點

上面基本描述了MQ的優(yōu)點,在一定的場景下實現(xiàn)解耦、異步、削峰等問題。

2.2.缺點

  • 系統(tǒng)可用性降低

    系統(tǒng)引入的外部依賴越多,越容易掛掉。本來你就是 A 系統(tǒng)調(diào)用 BCD 三個系統(tǒng)的接口就好了,ABCD 四個系統(tǒng)還好好的,沒啥問題,你偏加個 MQ 進來,萬一 MQ 掛了咋整?MQ 一掛,整套系統(tǒng)崩潰,你不就完了?如何保證消息隊列的高可用?

  • 系統(tǒng)復雜度提高

    不管是開發(fā)還是運維,加入MQ之后,系統(tǒng)的復雜度變高了,維護成本變高,而且會面臨怎么保證消息沒有重復消費?怎么處理消息丟失的情況?怎么保證消息傳遞的順序性?等

  • 一致性問題

    異步中場景,A系統(tǒng)下發(fā)到MQ之后就直接返回瀏覽器成功,人都以為你這個請求就成功了;但是問題是,要是 BCD 三個系統(tǒng)那里,BD 兩個系統(tǒng)寫庫成功了,結(jié)果 C 系統(tǒng)寫庫失敗了,就會造成不一致性問題。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容