[[396992]]

 消息隊(duì)列中間件是分布式系統(tǒng)中重要的組件之一，在高并發(fā)的系統(tǒng)中是更是必不可少的，主要解決應(yīng)用耦合，異步消息，流量削鋒等問題。實(shí)現(xiàn)高性能、高可用、可伸縮和最終一致性架構(gòu)。使用較多的消息隊(duì)列有ActiveMQ、RabbitMQ、Kafka、RocketMQ。今天講講消息隊(duì)列在高并發(fā)系統(tǒng)中的具體應(yīng)用場(chǎng)景和注意事項(xiàng)

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

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

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

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

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

1. 異步處理，通過異步處理提高系統(tǒng)性能，減少響應(yīng)所需時(shí)間
2. 流量削峰，避免高并發(fā)訪問直接把數(shù)據(jù)庫(kù)搞掛
3. 應(yīng)用解耦，降低系統(tǒng)耦合性

2.1、異步處理

同步處理過程

異步處理過程

將用戶的請(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ù)后，再通過電子郵件或短信通知用戶訂單成功，以免交易糾紛。這就類似我們用手機(jī)訂火車票和電影票。

2.2 流量削峰

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

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

2.3 應(yīng)用解耦

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

假設(shè)有這樣的一個(gè)場(chǎng)景：A系統(tǒng)發(fā)送數(shù)據(jù)到B、C、D三個(gè)系統(tǒng)，通過接口調(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ā)送過來。A系統(tǒng)要時(shí)時(shí)刻刻考慮B、C、D、E四個(gè)系統(tǒng)如果掛了該怎么辦?要不要重發(fā)，要不要把消息存起來?頭發(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)即可。這樣下來，A系統(tǒng)壓根兒不需要去考慮要給誰發(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)者)之間沒有直接耦合，消息發(fā)送者將消息發(fā)送至分布式消息隊(duì)列即結(jié)束對(duì)消息的處理，消息接受者從分布式消息隊(duì)列獲取該消息后進(jìn)行后續(xù)處理，并不需要知道該消息從何而來。對(duì)新增業(yè)務(wù)，只要對(duì)該類消息感興趣，即可訂閱該消息，對(duì)原有系統(tǒng)和業(yè)務(wù)沒有任何影響，從而實(shí)現(xiàn)系統(tǒng)業(yè)務(wù)的可擴(kuò)展性設(shè)計(jì)。

三、使用消息隊(duì)列帶來的一些問題

• 系統(tǒng)可用性降低： 系統(tǒng)可用性在某種程度上降低，系統(tǒng)引入的外部依賴越多，越容易掛掉。在加入MQ之前，我們不用考慮消息丟失或者說MQ掛掉等等的情況，但是，引入MQ之后需要去考慮如何保證消息隊(duì)列的高可用，否則MQ一掛就有可能導(dǎo)致整套系統(tǒng)崩潰!
• 系統(tǒng)復(fù)雜性提高： 加入MQ之后，我們需要保證消息沒有被重復(fù)消費(fèi)、處理消息丟失的情況、保證消息傳遞的順序性等等問題!
• 數(shù)據(jù)一致性問題： 上面講了消息隊(duì)列可以實(shí)現(xiàn)異步，消息隊(duì)列帶來的異步確實(shí)可以提高系統(tǒng)響應(yīng)速度。但是，萬一消息的真正消費(fèi)者并沒有正確消費(fèi)消息怎么辦?這樣就會(huì)導(dǎo)致數(shù)據(jù)不一致的情況!

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

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

總結(jié)：

• ActiveMQ：的社區(qū)算是比較成熟，但是較目前來說，ActiveMQ的性能比較差，而且版本迭代很慢，不推薦使用。
• RabbitMQ：在吞吐量方面雖然稍遜于Kafka和RocketMQ ，但是由于它基于erlang開發(fā)，所以并發(fā)能力很強(qiáng)，性能極其好，延時(shí)很低，達(dá)到微秒級(jí)。但是也因?yàn)镽abbitMQ基于erlang開發(fā)，所以國(guó)內(nèi)很少有公司有實(shí)力做erlang源碼級(jí)別的研究和定制。如果業(yè)務(wù)場(chǎng)景對(duì)并發(fā)量要求不是太高(十萬級(jí)、百萬級(jí))，那這四種消息隊(duì)列中，RabbitMQ一定是你的首選。如果是大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)計(jì)算、日志采集等場(chǎng)景，用Kafka是業(yè)內(nèi)標(biāo)準(zhǔn)的，絕對(duì)沒問題，社區(qū)活躍度很高，絕對(duì)不會(huì)黃，何況幾乎是全世界這個(gè)領(lǐng)域的事實(shí)性規(guī)范。
• RocketMQ：阿里出品，Java系開源項(xiàng)目，源代碼我們可以直接閱讀，然后可以定制自己公司的MQ，并且 RocketMQ有阿里巴巴的實(shí)際業(yè)務(wù)場(chǎng)景的實(shí)戰(zhàn)考驗(yàn)。RocketMQ 社區(qū)活躍度相對(duì)較為一般，目前RocketMQ已捐給 Apache，但 GitHub 上的活躍度其實(shí)不算高，文檔相對(duì)來說簡(jiǎn)單一些，然后接口這塊不是按照標(biāo)準(zhǔn) JMS 規(guī)范走的有些系統(tǒng)要遷移需要修改大量代碼。還有就是阿里出臺(tái)的技術(shù)，你得做好這個(gè)技術(shù)萬一被拋棄，社區(qū)黃掉的風(fēng)險(xiǎn)，對(duì)自己公司技術(shù)實(shí)力有絕對(duì)自信的，推薦用 RocketMQ，否則回去老老實(shí)實(shí)用RabbitMQ吧，人家有活躍的開源社區(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ì)算以及日志收集。