[[396992]]

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

一、什么是消息隊列

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

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

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

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

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

2.1、異步處理

同步處理過程

異步處理過程

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

2.2 流量削峰

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

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

2.3 應用解耦

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

假設有這樣的一個場景：A系統發送數據到B、C、D三個系統，通過接口調用發送。如果E系統也要這個數據呢?那如果C系統現在不需要了呢?A系統負責人幾乎要改到崩潰......

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

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

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

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

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

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

四、常用消息隊列對比

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

總結：

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