消息隊列（MQ）介紹

概念

消息隊列（MQ）

消息隊列（Message Queue，簡稱MQ），從字面意思上看，本質是個隊列，FIFO先入先出，只不過隊列中存放的內容是message而已。
其主要用途：不同進程Process/線程Thread之間通信。

MQ框架

MQ框架非常之多，比較流行的有RabbitMq、ActiveMq、ZeroMq、kafka，以及阿里開源的RocketMQ。

AMQP協議

AMQP，即Advanced Message Queuing Protocol，一個提供統一消息服務的應用層標準高級消息隊列協議，是應用層協議的一個開放標準，爲面向消息的中間件設計。基於此協議的客戶端與消息中間件可傳遞消息，並不受客戶端/中間件不同產品，不同的開發語言等條件的限制。

MQ系統組成單元

消息生產者（Producer）

消息消費者（Consumer）

消息服務（Broker）

虛擬主機（Visual Host）

其中Producer與Consumer組成客戶端，Broker是服務端。Broker裏可以有多個Visual Host，用作不同用戶的權限分離。

MQ框架對比

參考：https://blog.csdn.net/a519781181/article/details/79005206

ZeroMQ：擴展性好，開發比較靈活，採用C語言實現，實際上他只是一個socket庫的重新封裝，如果我們做爲消息隊列使用，需要開發大量的代碼。

RabbitMQ：結合erlang語言本身的併發優勢，性能較好，但是不利於做二次開發和維護。

ActiveMQ：歷史悠久的開源項目，已經在很多產品中得到應用，實現了JMS1.1規範，可以和spring-jms輕鬆融合，實現了多種協議，不夠輕巧（源代碼比RocketMQ多）.，支持持久化到數據庫，對隊列數較多的情況支持不好，不過我們的項目中並不會建很多的隊列。

Redis：做爲一個基於內存的K-V數據庫，其提供了消息訂閱的服務，可以當作MQ來使用，目前應用案例較少，且不方便擴展。

RocketMQ：阿里巴巴的MQ中間件，在其多個產品下使用，並能夠撐住雙十一的大流量，他並沒有實現JMS規範，使用起來很簡單。部署由一個 命名服務（nameserver）和一個代理（broker）組成，nameserver和broker以及producer都支持集羣，隊列的容量受機器硬盤的限制，隊列滿後可以支持持久化到硬盤（也可以自己適配代碼，將其持久化到NOSQL數據庫中），隊列滿後會影響吞吐量，可以採用主備來保證穩定性，支持回溯消費，可以在broker端進行消息過濾。

1.從社區活躍度

按照目前網絡上的資料，RabbitMQ 、activeM 、ZeroMQ 三者中，綜合來看，RabbitMQ 是首選。

2.持久化消息比較

ZeroMq 不支持，ActiveMq 和RabbitMq 都支持。持久化消息主要是指我們機器在不可抗力因素等情況下掛掉了，消息不會丟失的機制。

3.綜合技術實現

可靠性、靈活的路由、集羣、事務、高可用的隊列、消息排序、問題追蹤、可視化管理工具、插件系統等等。
RabbitMq / Kafka 最好，ActiveMq 次之，ZeroMq 最差。當然ZeroMq 也可以做到，不過自己必須手動寫代碼實現，代碼量不小。尤其是可靠性中的：持久性、投遞確認、發佈者證實和高可用性。

4.高併發

毋庸置疑，RabbitMQ 最高，原因是它的實現語言是天生具備高併發高可用的erlang 語言。

5.比較關注的比較， RabbitMQ 和 Kafka

RabbitMq 比Kafka 成熟，在可用性上，穩定性上，可靠性上， RabbitMq 勝於 Kafka （理論上）。
另外，Kafka 的定位主要在日誌等方面， 因爲Kafka 設計的初衷就是處理日誌的，可以看做是一個日誌（消息）系統一個重要組件，針對性很強，所以 如果業務方面還是建議選擇 RabbitMq 。
還有就是，Kafka 的性能（吞吐量、TPS ）比RabbitMq 要高出來很多。

RabbitMQ介紹

參考資料：https://www.sojson.com/blog/48.html

AMQP，即Advanced Message Queuing Protocol，高級消息隊列協議，是應用層協議的一個開放標準，爲面向消息的中間件設計。消息中間件主要用於組件之間的解耦，消息的發送者無需知道消息使用者的存在，反之亦然。 AMQP的主要特徵是面向消息、隊列、路由（包括點對點和發佈/訂閱）、可靠性、安全。 RabbitMQ是一個開源的AMQP實現，服務器端用Erlang語言編寫，支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用於在分佈式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。

幾個基礎概念：

1、ConnectionFactory、Connection、Channel

ConnectionFactory、Connection、Channel都是RabbitMQ對外提供的API中最基本的對象。Connection是RabbitMQ的socket鏈接，它封裝了socket協議相關部分邏輯。ConnectionFactory爲Connection的製造工廠。 Channel是我們與RabbitMQ打交道的最重要的一個接口，我們大部分的業務操作是在Channel這個接口中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發佈消息等。

2、Queue

Queue（隊列）是RabbitMQ的內部對象，用於存儲消息，用下圖表示。

RabbitMQ中的消息都只能存儲在Queue中，生產者生產消息並最終投遞到Queue中，消費者可以從Queue中獲取消息並消費。

多個消費者可以訂閱同一個Queue，這時Queue中的消息會被平均分攤給多個消費者進行處理，而不是每個消費者都收到所有的消息並處理。

3、Exchange

在上一節我們看到生產者將消息投遞到Queue中，實際上這在RabbitMQ中這種事情永遠都不會發生。實際的情況是，生產者將消息發送到Exchange，由Exchange將消息路由到一個或多個Queue中（或者丟棄）。

4、routing key

生產者在將消息發送給Exchange的時候，一般會指定一個routing key，來指定這個消息的路由規則，而這個routing key需要與Exchange Type及binding key聯合使用才能最終生效。 在Exchange Type與binding key固定的情況下（在正常使用時一般這些內容都是固定配置好的），我們的生產者就可以在發送消息給Exchange時，通過指定routing key來決定消息流向哪裏。

5、Binding

RabbitMQ中通過Binding將Exchange與Queue關聯起來，這樣RabbitMQ就知道如何正確地將消息路由到指定的Queue了。

6、Binding key

在綁定（Binding）Exchange與Queue的同時，一般會指定一個binding key；消費者將消息發送給Exchange時，一般會指定一個routing key；當binding key與routing key相匹配時，消息將會被路由到對應的Queue中。這個將在Exchange Types章節會列舉實際的例子加以說明。 在綁定多個Queue到同一個Exchange的時候，這些Binding允許使用相同的binding key。 binding key 並不是在所有情況下都生效，它依賴於Exchange Type，比如fanout類型的Exchange就會無視binding key，而是將消息路由到所有綁定到該Exchange的Queue。

7、Exchange Types

RabbitMQ常用的Exchange Type有fanout、direct、topic、headers這四種（AMQP規範裏還提到兩種Exchange Type，分別爲system與自定義，這裏不予以描述），下面分別進行介紹。

• direct

direct類型的Exchange路由規則也很簡單，它會把消息路由到那些binding key與routing key完全匹配的Queue中。

• fanout

fanout類型的Exchange路由規則非常簡單，它會把所有發送到該Exchange的消息路由到所有與它綁定的Queue中。

• topic

前面講到direct類型的Exchange路由規則是完全匹配binding key與routing key，但這種嚴格的匹配方式在很多情況下不能滿足實際業務需求。topic類型的Exchange在匹配規則上進行了擴展，它與direct類型的Exchage相似，也是將消息路由到binding key與routing key相匹配的Queue中，但這裏的匹配規則有些不同，它約定：

routing key爲一個句點號“. ”分隔的字符串（我們將被句點號“. ”分隔開的每一段獨立的字符串稱爲一個單詞），如 “stock.usd.nyse”、 “nyse.vmw”、 “quick.orange.rabbit”。

binding key與routing key一樣也是句點號“. ”分隔的字符串。

binding key中可以存在兩種特殊字符“”與“#”，用於做模糊匹配，其中“”用於匹配一個單詞，“#”用於匹配多個單詞（可以是零個）。

RabbitMQ Server安裝配置

參考資料：https://blog.csdn.net/jian200801/article/details/105289349

erlang

RabbitMQ Server 需要erlang運行時，所以需要首先安裝erlang，並且erlang的版本要與RabbitMQ匹配。

RabbitMQ Server

下載RabbitMQ Server壓縮包，解壓、配置環境變量即可。

RabbitMQ 插件

RabbitMQ提供了很多插件，其中最常用的就是rabbitmq_management插件，它提供一個web管理平臺，提供系統、連接、信道、交換機、隊列等各個模塊的監控頁面，同時還提供了後臺管理功能。

Springboot集成RabbitMQ

參考資料：https://blog.csdn.net/jian200801/article/details/105289349

spring-amqp項目集成了RabbitMQ，實現了連接的的自動配置以及管理，並且spring-amqp還提供了rabbitTemplate模版，可以方便、快速地完成消息的發送和接收。