消息隊(duì)列應(yīng)用場(chǎng)景和注意事項(xiàng)有哪些

本篇內(nèi)容主要講解“消息隊(duì)列應(yīng)用場(chǎng)景和注意事項(xiàng)有哪些”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“消息隊(duì)列應(yīng)用場(chǎng)景和注意事項(xiàng)有哪些”吧!

一、什么是消息隊(duì)列

我們可以把消息隊(duì)列看作是一個(gè)存放消息的容器，當(dāng)我們需要使用消息的時(shí)候，直接從容器中取出消息供自己使用即可。

隊(duì)列Queue是一種先進(jìn)先出的數(shù)據(jù)結(jié)構(gòu)，所以消費(fèi)消息時(shí)也是按照順序來(lái)消費(fèi)的。

二、為什么要使用消息隊(duì)列

通常來(lái)說(shuō)，使用消息隊(duì)列能為我們的系統(tǒng)帶來(lái)下面三點(diǎn)好處：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 異步處理，通過(guò)異步處理提高系統(tǒng)性能，減少響應(yīng)所需時(shí)間

3. 流量削峰，避免高并發(fā)訪問(wèn)直接把數(shù)據(jù)庫(kù)搞掛

4. 應(yīng)用解耦，降低系統(tǒng)耦合性

2.1、異步處理

同步處理過(guò)程

異步處理過(guò)程

將用戶的請(qǐng)求數(shù)據(jù)存儲(chǔ)到消息隊(duì)列之后就立即返回結(jié)果。隨后，系統(tǒng)再對(duì)消息進(jìn)行消費(fèi)。因?yàn)橛脩粽?qǐng)求數(shù)據(jù)寫入消息隊(duì)列之后就立即返回給用戶了，但是請(qǐng)求數(shù)據(jù)在后續(xù)的業(yè)務(wù)校驗(yàn)、寫數(shù)據(jù)庫(kù)等操作中可能失敗。因此，使用消息隊(duì)列進(jìn)行異步處理之后，需要適當(dāng)修改業(yè)務(wù)流程進(jìn)行配合，比如用戶在提交訂單之后，訂單數(shù)據(jù)寫入消息隊(duì)列，不能立即返回用戶訂單提交成功，需要在消息隊(duì)列的訂單消費(fèi)者進(jìn)程真正處理完該訂單之后，甚至出庫(kù)后，再通過(guò)電子郵件或短信通知用戶訂單成功，以免交易糾紛。這就類似我們用手機(jī)訂火車票和電影票。

2.2 流量削峰

先將短時(shí)間高并發(fā)產(chǎn)生的事務(wù)消息存儲(chǔ)在消息隊(duì)列中，然后后端服務(wù)再慢慢根據(jù)自己的能力去消費(fèi)這些消息，這樣就避免直接把后端服務(wù)打垮掉。

例如：在電子商務(wù)一些秒殺、促銷活動(dòng)中，合理使用消息隊(duì)列可以有效抵御促銷活動(dòng)剛開(kāi)始大量訂單涌入對(duì)系統(tǒng)的沖擊。如下圖所示：

2.3 應(yīng)用解耦

使用消息隊(duì)列還可以降低系統(tǒng)耦合性。我們知道如果模塊之間不存在直接調(diào)用，那么新增模塊或者修改模塊就對(duì)其他模塊影響較小，這樣系統(tǒng)的可擴(kuò)展性無(wú)疑更好一些。

假設(shè)有這樣的一個(gè)場(chǎng)景：A系統(tǒng)發(fā)送數(shù)據(jù)到B、C、D三個(gè)系統(tǒng)，通過(guò)接口調(diào)用發(fā)送。如果E系統(tǒng)也要這個(gè)數(shù)據(jù)呢?那如果C系統(tǒng)現(xiàn)在不需要了呢?A系統(tǒng)負(fù)責(zé)人幾乎要改到崩潰......

在這個(gè)場(chǎng)景中，A  系統(tǒng)跟其它各種亂七八糟的系統(tǒng)嚴(yán)重耦合，A系統(tǒng)產(chǎn)生一條比較關(guān)鍵的數(shù)據(jù)，很多系統(tǒng)都需要A系統(tǒng)將這個(gè)數(shù)據(jù)發(fā)送過(guò)來(lái)。A系統(tǒng)要時(shí)時(shí)刻刻考慮B、C、D、E四個(gè)系統(tǒng)如果掛了該怎么辦?要不要重發(fā)，要不要把消息存起來(lái)?頭發(fā)都白了啊!

如果使用MQ，A系統(tǒng)產(chǎn)生一條數(shù)據(jù)，發(fā)送到MQ里面去，哪個(gè)系統(tǒng)需要數(shù)據(jù)自己去MQ里面消費(fèi)。如果新系統(tǒng)需要數(shù)據(jù)，直接從MQ里消費(fèi)即可;如果某個(gè)系統(tǒng)不需要這條數(shù)據(jù)了，就取消對(duì)MQ消息的消費(fèi)即可。這樣下來(lái)，A系統(tǒng)壓根兒不需要去考慮要給誰(shuí)發(fā)送數(shù)據(jù)，不需要維護(hù)這個(gè)代碼，也不需要考慮人家是否調(diào)用成功、失敗超時(shí)等情況。如下圖所示：

生產(chǎn)者(客戶端)發(fā)送消息到消息隊(duì)列中去，接受者(服務(wù)端)處理消息，需要消費(fèi)的系統(tǒng)直接去消息隊(duì)列取消息進(jìn)行消費(fèi)即可而不需要和其他系統(tǒng)有耦合，  這顯然也提高了系統(tǒng)的擴(kuò)展性。

消息隊(duì)列是用發(fā)布-訂閱模式工作，消息發(fā)送者(生產(chǎn)者)發(fā)布消息，一個(gè)或多個(gè)消息接受者(消費(fèi)者)訂閱消息。  從上圖可以看到消息發(fā)送者(生產(chǎn)者)和消息接受者(消費(fèi)者)之間沒(méi)有直接耦合，消息發(fā)送者將消息發(fā)送至分布式消息隊(duì)列即結(jié)束對(duì)消息的處理，消息接受者從分布式消息隊(duì)列獲取該消息后進(jìn)行后續(xù)處理，并不需要知道該消息從何而來(lái)。對(duì)新增業(yè)務(wù)，只要對(duì)該類消息感興趣，即可訂閱該消息，對(duì)原有系統(tǒng)和業(yè)務(wù)沒(méi)有任何影響，從而實(shí)現(xiàn)系統(tǒng)業(yè)務(wù)的可擴(kuò)展性設(shè)計(jì)。

三、使用消息隊(duì)列帶來(lái)的一些問(wèn)題

• 系統(tǒng)可用性降低：  系統(tǒng)可用性在某種程度上降低，系統(tǒng)引入的外部依賴越多，越容易掛掉。在加入MQ之前，我們不用考慮消息丟失或者說(shuō)MQ掛掉等等的情況，但是，引入MQ之后需要去考慮如何保證消息隊(duì)列的高可用，否則MQ一掛就有可能導(dǎo)致整套系統(tǒng)崩潰!

• 系統(tǒng)復(fù)雜性提高： 加入MQ之后，我們需要保證消息沒(méi)有被重復(fù)消費(fèi)、處理消息丟失的情況、保證消息傳遞的順序性等等問(wèn)題!

• 數(shù)據(jù)一致性問(wèn)題：  上面講了消息隊(duì)列可以實(shí)現(xiàn)異步，消息隊(duì)列帶來(lái)的異步確實(shí)可以提高系統(tǒng)響應(yīng)速度。但是，萬(wàn)一消息的真正消費(fèi)者并沒(méi)有正確消費(fèi)消息怎么辦?這樣就會(huì)導(dǎo)致數(shù)據(jù)不一致的情況!

四、常用消息隊(duì)列對(duì)比

市面上有很多MQ產(chǎn)品，主流的就是Kafka、ActiveMQ、RabbitMQ、RocketMQ這四種，但是我們?cè)谧黾夹g(shù)選型的時(shí)候該用哪一個(gè)呢?每一個(gè)MQ沒(méi)有絕對(duì)的好壞，就是看用在哪個(gè)場(chǎng)景可以揚(yáng)長(zhǎng)避短，利用其優(yōu)勢(shì)，規(guī)避其劣勢(shì)。

總結(jié)：

• ActiveMQ：的社區(qū)算是比較成熟，但是較目前來(lái)說(shuō)，ActiveMQ的性能比較差，而且版本迭代很慢，不推薦使用。

• RabbitMQ：在吞吐量方面雖然稍遜于Kafka和RocketMQ  ，但是由于它基于erlang開(kāi)發(fā)，所以并發(fā)能力很強(qiáng)，性能極其好，延時(shí)很低，達(dá)到微秒級(jí)。但是也因?yàn)镽abbitMQ基于erlang開(kāi)發(fā)，所以國(guó)內(nèi)很少有公司有實(shí)力做erlang源碼級(jí)別的研究和定制。如果業(yè)務(wù)場(chǎng)景對(duì)并發(fā)量要求不是太高(十萬(wàn)級(jí)、百萬(wàn)級(jí))，那這四種消息隊(duì)列中，RabbitMQ一定是你的首選。如果是大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)計(jì)算、日志采集等場(chǎng)景，用Kafka是業(yè)內(nèi)標(biāo)準(zhǔn)的，絕對(duì)沒(méi)問(wèn)題，社區(qū)活躍度很高，絕對(duì)不會(huì)黃，何況幾乎是全世界這個(gè)領(lǐng)域的事實(shí)性規(guī)范。

• RocketMQ：阿里出品，Java系開(kāi)源項(xiàng)目，源代碼我們可以直接閱讀，然后可以定制自己公司的MQ，并且  RocketMQ有阿里巴巴的實(shí)際業(yè)務(wù)場(chǎng)景的實(shí)戰(zhàn)考驗(yàn)。RocketMQ 社區(qū)活躍度相對(duì)較為一般，目前RocketMQ已捐給 Apache，但 GitHub  上的活躍度其實(shí)不算高，文檔相對(duì)來(lái)說(shuō)簡(jiǎn)單一些，然后接口這塊不是按照標(biāo)準(zhǔn) JMS  規(guī)范走的有些系統(tǒng)要遷移需要修改大量代碼。還有就是阿里出臺(tái)的技術(shù)，你得做好這個(gè)技術(shù)萬(wàn)一被拋棄，社區(qū)黃掉的風(fēng)險(xiǎn)，對(duì)自己公司技術(shù)實(shí)力有絕對(duì)自信的，推薦用  RocketMQ，否則回去老老實(shí)實(shí)用RabbitMQ吧，人家有活躍的開(kāi)源社區(qū)，絕對(duì)不會(huì)黃。

• Kafka：特點(diǎn)其實(shí)很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms級(jí)的延遲，極高的可用性以及可靠性，而且分布式可以任意擴(kuò)展。同時(shí)kafka最好是支撐較少的topic數(shù)量即可，保證其超高吞吐量。kafka唯一的一點(diǎn)劣勢(shì)是有可能消息重復(fù)消費(fèi)，那么對(duì)數(shù)據(jù)準(zhǔn)確性會(huì)造成極其輕微的影響，在大數(shù)據(jù)領(lǐng)域中以及日志采集中，這點(diǎn)輕微影響可以忽略這個(gè)特性天然適合大數(shù)據(jù)實(shí)時(shí)計(jì)算以及日志收集。

到此，相信大家對(duì)“消息隊(duì)列應(yīng)用場(chǎng)景和注意事項(xiàng)有哪些”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！