前面集中談了分布式緩存Redis系列：

高并發(fā)架構(gòu)系列：分布式鎖的由來、特點、及Redis分布式鎖的實現(xiàn)詳解

高并發(fā)架構(gòu)系列：Redis并發(fā)競爭key的解決方案詳解

高并發(fā)架構(gòu)系列：Redis緩存和MySQL數(shù)據(jù)一致性方案詳解

Redis的高可用詳解：Redis哨兵、復(fù)制、集群的設(shè)計原理，以及區(qū)別

高并發(fā)架構(gòu)系列：Redis為什么是單線程、及高并發(fā)快的3大原因詳解

如何解決Redis緩存雪崩、緩存穿透、緩存并發(fā)等5大難題

今天我們開始分布式之消息隊列之旅。

什么是消息隊列

消息隊列（Message Queue，簡稱MQ），指保存消息的一個容器，本質(zhì)是個隊列。

消息（Message）是指在應(yīng)用之間傳送的數(shù)據(jù)，消息可以非常簡單，比如只包含文本字符串，也可以更復(fù)雜，可能包含嵌入對象。

消息隊列（Message Queue）是一種應(yīng)用間的通信方式，消息發(fā)送后可以立即返回，有消息系統(tǒng)來確保信息的可靠專遞，消息發(fā)布者只管把消息發(fā)布到MQ中而不管誰來取，消息使用者只管從MQ中取消息而不管誰發(fā)布的，這樣發(fā)布者和使用者都不用知道對方的存在。

• Producer：消息生產(chǎn)者，負(fù)責(zé)產(chǎn)生和發(fā)送消息到 Broker；
• Broker：消息處理中心。負(fù)責(zé)消息存儲、確認(rèn)、重試等，一般其中會包含多個 queue；
• Consumer：消息消費者，負(fù)責(zé)從 Broker 中獲取消息，并進(jìn)行相應(yīng)處理；

現(xiàn)在常用的MQ組件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ,當(dāng)然近年來火熱的Kafka,從某些場景來說，也是MQ，當(dāng)然kafka的功能更加強大。

雖然不同的MQ都有自己的特點和優(yōu)勢，但是，不管是哪種MQ，都有MQ本身自帶的一些特點，下面，咱們談?wù)勏㈥犃械牡奶攸c、優(yōu)勢、選型、以及應(yīng)用場景。

為什么需要消息隊列

在高并發(fā)分布式環(huán)境下，由于來不及同步處理，通過使用消息隊列，可以異步處理請求，從而緩解系統(tǒng)的壓力。

舉一個訂單系統(tǒng)的例子：用戶點擊下訂單，會觸發(fā)以下業(yè)務(wù)邏輯流程：

• 扣減庫存
• 生成相應(yīng)的訂單
• 發(fā)短信通知等等

在業(yè)務(wù)發(fā)展初期這些邏輯可能放在一起同步執(zhí)行，隨著業(yè)務(wù)訂單量增長，需要提升系統(tǒng)服務(wù)的性能，這時候可以將一些不需要立即生效的操作拆分出來異步執(zhí)行，比如發(fā)短信通知等，這種場景就可以使用消息隊列MQ。

本質(zhì)還是通過異步來解決同步的系統(tǒng)壓力，所以我們在做架構(gòu)設(shè)計的時候有一個原則：能異步的就盡量不要同步。

消息隊列的優(yōu)點

1、屏蔽異構(gòu)平臺的細(xì)節(jié)：發(fā)送方、接收方系統(tǒng)之間不需要了解雙方，只需認(rèn)識消息。

2、異步：消息堆積能力；發(fā)送方接收方不需同時在線，發(fā)送方接收方不需同時擴容（削峰）。

3、解耦：防止引入過多的API給系統(tǒng)的穩(wěn)定性帶來風(fēng)險；調(diào)用方使用不當(dāng)會給被調(diào)用方系統(tǒng)造成壓力，被調(diào)用方處理不當(dāng)會降低調(diào)用方系統(tǒng)的響應(yīng)能力。

4、復(fù)用：一次發(fā)送多次消費。

5、可靠：一次保證消息的傳遞。如果發(fā)送消息時接收者不可用，消息隊列會保留消息，直到成功地傳遞它。

6、提供路由：發(fā)送者無需與接收者建立連接，雙方通過消息隊列保證消息能夠從發(fā)送者路由到接收者，甚至對于本來網(wǎng)絡(luò)不易互通的兩個服務(wù)，也可以提供消息路由。

消息隊列的特點

1.異步性

將耗時的同步操作，通過以發(fā)送消息的方式，進(jìn)行了異步化處理。減少了同步等待的時間。

2.松耦合

消息隊列減少了服務(wù)之間的耦合性，不同的服務(wù)可以通過消息隊列進(jìn)行通信，而不用關(guān)心彼此的實現(xiàn)細(xì)節(jié)，只要定義好消息的格式就行。

3.分布式

通過對消費者的橫向擴展，降低了消息隊列阻塞的風(fēng)險，以及單個消費者產(chǎn)生單點故障的可能性（當(dāng)然消息隊列本身也可以做成分布式集群）。

4.可靠性

消息隊列一般會把接收到的消息存儲到本地硬盤上（當(dāng)消息被處理完之后，存儲信息根據(jù)不同的消息隊列實現(xiàn)，有可能將其刪除），這樣即使應(yīng)用掛掉或者消息隊列本身掛掉，消息也能夠重新加載。

消息隊列的選型

1.ActiveMQ

Apache出品，最早使用的消息隊列產(chǎn)品，時間比較長了，最近版本更新比較緩慢。

2.RabbitMQ

RabbitMQ是erlang語言開發(fā)，結(jié)合erlang語言本身的并發(fā)優(yōu)勢，支持很多的協(xié)議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級，更適合于企業(yè)級的開發(fā)。性能較好，但是不利于做二次開發(fā)和維護(hù)。

3.RocketMQ

阿里開源的消息中間件，純Java開發(fā)，具有高吞吐量、高可用性、適合大規(guī)模分布式系統(tǒng)應(yīng)用的特點。

4.ZeroMQ

號稱最快的消息隊列系統(tǒng)，尤其針對大吞吐量的需求場景。

擴展性好，開發(fā)比較靈活，采用C語言實現(xiàn)，實際上只是一個socket庫的重新封裝，如果做為消息隊列使用，需要開發(fā)大量的代碼。

5.Kafka

Kafka是Apache下的一個子項目，是一個高性能跨語言分布式發(fā)布/訂閱消息隊列系統(tǒng)，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。

6.消息隊列的詳細(xì)比較

7.消息隊列總結(jié)

消息隊列的選型需要根據(jù)具體應(yīng)用需求而定，ZeroMQ小而美，RabbitMQ大而穩(wěn)，Kakfa和RocketMQ快而強勁。

消息隊列的應(yīng)用場景

1.異步處理

消息隊列的主要特點是異步處理，主要目的是減少請求響應(yīng)時間，實現(xiàn)非核心流程異步化，提高系統(tǒng)響應(yīng)性能。

所以典型的使用場景就是將比較耗時而且不需要即時（同步）返回結(jié)果的操作，作為消息放入消息隊列。

2.應(yīng)用解耦

使用了消息隊列后，只要保證消息格式不變，消息的發(fā)送方和接收方并不需要彼此聯(lián)系，也不需要受對方的影響，即解耦。

每個成員不必受其他成員影響，可以更獨立自主，只通過消息隊列MQ來聯(lián)系。

舉一個例子：用戶下訂單流程，下訂單后會發(fā)生扣庫存這個動作，上游系統(tǒng)訂單和下游系統(tǒng)扣庫存，就可以通過上圖的消息隊列MQ來聯(lián)系，扣庫存異步化，從而實現(xiàn)訂單系統(tǒng)與庫存系統(tǒng)的應(yīng)用解耦。

3.流量削鋒

流量削鋒也是消息隊列中的常用場景，一般在秒殺或團(tuán)搶活動中使用廣泛。

應(yīng)用場景：秒殺活動，一般會因為流量過大，導(dǎo)致流量暴增，應(yīng)用掛掉。為解決這個問題，一般需要在應(yīng)用前端加入消息隊列。

具體可以參考：阿里P8架構(gòu)師談：雙11秒殺系統(tǒng)如何設(shè)計？

4日志處理

日志處理是指將消息隊列用在日志處理中，比如Kafka的應(yīng)用，解決大量日志傳輸?shù)膯栴}。

5消息通訊

消息隊列一般都內(nèi)置了高效的通信機制，因此也可以用于單純的消息通訊，比如實現(xiàn)點對點消息隊列或者聊天室等。

你可能也喜歡:

消息中間件系列(九)：詳解RocketMQ的架構(gòu)設(shè)計、關(guān)鍵特性、與應(yīng)用場景

消息中間件系列（三）：主流的消息隊列中間件有哪些？

消息中間件系列（一）：消息中間件介紹、典型使用場景、以及使用原則

消息中間件系列(二)：Kafka的原理、基礎(chǔ)架構(gòu)、以及使用場景

消息中間件系列(五)：MQ消息隊列的12點核心原理總結(jié)

消息中間件系列（六）：什么是流量削峰？如何解決秒殺業(yè)務(wù)的削峰場景

---

總結(jié)

以上是生活随笔為你收集整理的消息中间件系列(四)：消息队列MQ的特点、选型、及应用场景详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。