關(guān)于消息隊列的優(yōu)缺點(diǎn),看這篇就行

在項目中為什么要使用消息隊列

岐山網(wǎng)站制作公司哪家好,找創(chuàng)新互聯(lián)建站!從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站開發(fā)等網(wǎng)站項目制作,到程序開發(fā),運(yùn)營維護(hù)。創(chuàng)新互聯(lián)建站從2013年創(chuàng)立到現(xiàn)在10年的時間,我們擁有了豐富的建站經(jīng)驗和運(yùn)維經(jīng)驗,來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。

消息隊列使用場景主要有三個:

解耦,異步,削峰

1、解耦

關(guān)于消息隊列的優(yōu)缺點(diǎn),看這篇就行

如上圖所示,可能存在某一個系統(tǒng)產(chǎn)生關(guān)鍵數(shù)據(jù),所有系統(tǒng)都需要其進(jìn)行提供數(shù)據(jù),導(dǎo)致A系統(tǒng)與要提供數(shù)據(jù)系統(tǒng)產(chǎn)生耦合,系統(tǒng)拓展,其他系統(tǒng)的需求修改都會導(dǎo)致A系統(tǒng)產(chǎn)生修改。

關(guān)于消息隊列的優(yōu)缺點(diǎn),看這篇就行

2、異步

關(guān)于消息隊列的優(yōu)缺點(diǎn),看這篇就行

如果用戶一個點(diǎn)擊,需要幾個系統(tǒng)間的一系列反應(yīng),同時每一個系統(tǒng)肯都存在一定的耗時,那么可以使用mq對不同的系統(tǒng)進(jìn)行發(fā)送命令,進(jìn)行異步操作。

關(guān)于消息隊列的優(yōu)缺點(diǎn),看這篇就行

3、削峰

關(guān)于消息隊列的優(yōu)缺點(diǎn),看這篇就行

主要是如果存在用戶使用的高峰期,例如存在大量的請求訪問數(shù)據(jù)庫(MySQL每秒2000個請求),超過就會卡死,我們使用MQ作為類似于緩沖區(qū)的作用,高峰取時在MQ中進(jìn)行大量請求積壓,處理器按照自己的最大處理能力取請求量,等請求期過后再把它消耗掉。

關(guān)于消息隊列的優(yōu)缺點(diǎn),看這篇就行

消息隊列有什么缺點(diǎn)

1、系統(tǒng)的可用性降低:很多服務(wù)都依賴于MQ,一旦MQ故障,系統(tǒng)崩潰。

2、系統(tǒng)變的復(fù)雜,序列考慮問題變多:發(fā)送消息重復(fù),多了,亂序,丟掉。

3.、一致性問題:系統(tǒng)A給BCD發(fā)送,只有都成功才返回成功,結(jié)果BC成功,但是D失敗,但是返回頁面結(jié)果是成功。

每一個MQ都有什么異同和適用場景

ActiveMQ

最早大家都用ActiveMQ,但是現(xiàn)在確實大家用的不多了,沒經(jīng)過大規(guī)模吞吐量場景的驗證,社區(qū)也不是很活躍,單機(jī)吞吐量,萬級,吞吐量比RocketMQ和Kafka要低了一個數(shù)量級,響應(yīng)為ms級別,有較低的概率丟失數(shù)據(jù)。

RabbitMQ

單機(jī)吞吐率萬級,吞吐量比RocketMQ和Kafka要低了一個數(shù)量級,但是適合于中小型企業(yè),因為自帶了友好的監(jiān)控和維護(hù)界面,社區(qū)相對比較活躍,幾乎每個月都發(fā)布幾個版本分,在國內(nèi)一些互聯(lián)網(wǎng)公司近幾年用rabbitmq也比較多一些,但是問題也是顯而易見的,RabbitMQ確實吞吐量會低一些,這是因為他做的實現(xiàn)機(jī)制比較重,同時語言在國內(nèi)很少有人會。

RocketMQ

單機(jī)吞吐量10萬級,RocketMQ也是可以支撐高吞吐的一種MQ,topic可以達(dá)到幾百,幾千個的級別,吞吐量會有較小幅度的下降,這是RocketMQ的一大優(yōu)勢,在同等機(jī)器下,可以支撐大量的topic,可用性非常高,分布式架構(gòu),在阿里大規(guī)模應(yīng)用過,有阿里品牌保障,日處理消息上百億之多,可以做到大規(guī)模吞吐,性能也非常好,分布式擴(kuò)展也很方便,源碼是JAVA。

Kafka

單機(jī)吞吐量10萬級別,這是kafka最大的優(yōu)點(diǎn),就是吞吐量高。一般配合大數(shù)據(jù)類的系統(tǒng)來進(jìn)行實時數(shù)據(jù)計算、日志采集等場景。topic從幾十個到幾百個的時候,吞吐量會大幅度下降。

所以在同等機(jī)器下,kafka盡量保證topic數(shù)量不要過多。如果要支撐大規(guī)模topic,需要增加更多的機(jī)器資源,可用性非常高,kafka是分布式的,一個數(shù)據(jù)多個副本,少數(shù)機(jī)器宕機(jī),不會丟失數(shù)據(jù),不會導(dǎo)致不可用。

標(biāo)題名稱:關(guān)于消息隊列的優(yōu)缺點(diǎn),看這篇就行
文章轉(zhuǎn)載:http://www.muchs.cn/article4/iidhoe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供電子商務(wù)ChatGPT、搜索引擎優(yōu)化、服務(wù)器托管、域名注冊網(wǎng)站維護(hù)

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)

成都做網(wǎng)站