[[396992]]

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

一、什么是消息隊列

我們可以把消息隊列看作是一個存放消息的容器，當我們需要使用消息的時候，直接從容器中取出消息供自己使用即可。

隊列Queue是一種先進先出的數(shù)據(jù)結構，所以消費消息時也是按照順序來消費的。

二、為什么要使用消息隊列

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

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

2.1、異步處理

同步處理過程

異步處理過程

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

2.2 流量削峰

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

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

2.3 應用解耦

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

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

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

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

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

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

三、使用消息隊列帶來的一些問題

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

四、常用消息隊列對比

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

總結：

• ActiveMQ：的社區(qū)算是比較成熟，但是較目前來說，ActiveMQ的性能比較差，而且版本迭代很慢，不推薦使用。
• RabbitMQ：在吞吐量方面雖然稍遜于Kafka和RocketMQ ，但是由于它基于erlang開發(fā)，所以并發(fā)能力很強，性能極其好，延時很低，達到微秒級。但是也因為RabbitMQ基于erlang開發(fā)，所以國內(nèi)很少有公司有實力做erlang源碼級別的研究和定制。如果業(yè)務場景對并發(fā)量要求不是太高(十萬級、百萬級)，那這四種消息隊列中，RabbitMQ一定是你的首選。如果是大數(shù)據(jù)領域的實時計算、日志采集等場景，用Kafka是業(yè)內(nèi)標準的，絕對沒問題，社區(qū)活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規(guī)范。
• RocketMQ：阿里出品，Java系開源項目，源代碼我們可以直接閱讀，然后可以定制自己公司的MQ，并且 RocketMQ有阿里巴巴的實際業(yè)務場景的實戰(zhàn)考驗。RocketMQ 社區(qū)活躍度相對較為一般，目前RocketMQ已捐給 Apache，但 GitHub 上的活躍度其實不算高，文檔相對來說簡單一些，然后接口這塊不是按照標準 JMS 規(guī)范走的有些系統(tǒng)要遷移需要修改大量代碼。還有就是阿里出臺的技術，你得做好這個技術萬一被拋棄，社區(qū)黃掉的風險，對自己公司技術實力有絕對自信的，推薦用 RocketMQ，否則回去老老實實用RabbitMQ吧，人家有活躍的開源社區(qū)，絕對不會黃。
• Kafka：特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms級的延遲，極高的可用性以及可靠性，而且分布式可以任意擴展。同時kafka最好是支撐較少的topic數(shù)量即可，保證其超高吞吐量。kafka唯一的一點劣勢是有可能消息重復消費，那么對數(shù)據(jù)準確性會造成極其輕微的影響，在大數(shù)據(jù)領域中以及日志采集中，這點輕微影響可以忽略這個特性天然適合大數(shù)據(jù)實時計算以及日志收集。