1 MQ 簡介

消息中間件利用高效可靠的消息傳遞機制進行平臺無關的數據交流，并基于數據通信來進行分布式系統的集成。通過提供消息傳遞和消息排隊模型，它可以在分布式環境下擴展進程間的通信。對于消息中間件，常見角色大致也就有 Producer（生產者）、Consumer（消費者）。

常見的消息中間件產品:

1). ActiveMQ

ActiveMQ 是 Apache 出品，最流行的，能力強勁的開源消息總線。ActiveMQ 是一個完全支持 JMS1.1 和 J2EE 1.4 規范的 JMS Provider 實現。我們在本次課程中介紹 ActiveMQ 的使用。

2). RabbitMQ

AMQP 協議的領導實現，支持多種場景。淘寶的 MySQL 集群內部有使用它進行通訊，

OpenStack 開源云平臺的通信組件，最先在金融行業得到運用。

3). ZeroMQ

史上最快的消息隊列系統

4). Kafka

Apache 下的一個子項目。特點：高吞吐，在一臺普通的服務器上既可以達到 10W/s

的吞吐速率；完全的分布式系統。適合處理海量數據

2 MQ 作用

1). 解耦 :中間件中的生產者只管發送消息 , 消費者只要從隊列當中獲取消息進行消費就可以 , 從而來實現業務的解耦 .

2). 冗余存儲 : 有些情況下，處理數據的過程會失敗。消息中間件可以把數據進行持久化直到它們已經被完全處理，通過這一方式規避了數據丟失風險。在把一個消息從消息中間件中刪除之前，需要你的處理系統明確地指出該消息己經被處理完成，從而確保你的數據被安全地保存直到你使用完畢。

3). 可恢復性: 當系統一部分組件失效時，不會影響到整個系統。消息中間件降低了進程間的稿合度，所以即使一個處理消息的進程掛掉，加入消息中間件中的消息仍然可以在系統恢復后進行處理。

4). 順序保證: 在大多數使用場景下，數據處理的順序很重要，大部分消息中間件支持一定程度上的順序性。

5). 緩沖: 在任何重要的系統中，都會存在需要不同處理時間的元素。消息中間件通過一個緩沖層來幫助任務最高效率地執行，寫入消息中間件的處理會盡可能快速。

6). 異步通信: 在很多時候應用不想也不需要立即處理消息。消息中間件提供了異步處理機制，允許應用把一些消息放入消息中間件中，但并不立即處理它，在之后需要的時候再慢慢處理。

3 RabbitMQ 安裝及啟動

3.1 安裝依賴環境

rpm -ivh erlang-20.3.8.6-1.el6.x86_64.rpm

yum -y install epel-release

yum -y install socat

3.2 安裝 rabbitMQ

rpm -ivh rabbitmq-server-3.7.7-1.el6.noarch.rpm

3.3 添加用戶

默認情況下管理界面只能在 linux 系統本機可以訪問, 如果想其他的主機也能訪問,需要配置:

rabbitmq-plugins enable rabbitmq_management

添加訪問用戶:

rabbitmqctl add_user admin admin

3.4 RabbitMQ 啟動/停止

啟動 : service rabbitmq-server start

停止: service rabbitmq-server stop

查看狀態: service rabbitmq-server status

4 Rabbit MQ 管理界面訪問

4.1 Overview 概要

該欄目主要展示的是 MQ 的概要信息 , 如消息的數量, Connection , Channel, Exchange , Queue , Consumer 的數量.

4.2 Exchange 交換器

該欄目主要展示的是當前虛擬主機下的交換器，也可以在此添加一個新的交換器，并且配置對應的交換器的規則屬性。

4.3 Queues 隊列

該欄目展示的是消息隊列的信息，里面有各個隊列的概要信息，也可以在此欄目添加隊列

Queue

4.4 Admin 系統管理

該欄目展示的是用戶管理的信息，包含用戶列表的展示，添加用戶，添加虛擬主機等信息

5 RabbitMQ 的相關概念

5.1 生產者與消費者

5.1.1 生產者

Producer: 生產者，就是投遞消息的一方。

生產者創建消息，然后發布到 RabbitMQ 中。消息一般可以包含 2 個部分:消息體和標簽 (Label)。消息體也可以稱之為 payload ，在實際應用中，消息體一般是一個帶有業務邏輯結構的數據，比如一個 JSON 字符串。當然可以進一步對這個消息體進行序列化操作。消息的標簽用來表述這條消息，比如一個交換器的名稱和一個路由鍵。生產者把消息交由 RabbitMQ ， RabbitMQ 之后會根據標簽把消息發送給感興趣的消費者(Consumer ) 。

5.1.2 消費者

Consumer: 消費者，就是接收消息的一方。

消費者連接到 RabbitMQ 服務器，并訂閱到隊列上。當消費者消費一條消息時，只是消費消息的消息體(payload )。在消息路由的過程中，消息的標簽會丟棄，存入到隊列中的消息只有消息體，消費者也只會消費到消息體，也就不知道消息的生產者是誰，當然消費者也不需要知道。

5.2 隊列

Queue: 隊列，是 RabbitMQ 的內部對象，用于存儲消息。

5.3 交換器, 路由鍵, 綁定

5.3.1 交換器

Exchange: 交換器。在上圖中我們暫時可以理解成生產者將消息投遞到隊列中，實際上這個在 RabbitMQ 中不會發生。真實情況是，生產者將消息發送到 Exchange (交換器)，由交換器將消息路由到一個或者多個隊列中。如果路由不到，或許會返回給生產者，或許直接丟棄。這里可以將RabbitMQ 中的交換器看作一個簡單的實體。

RabbitMQ 中的交換器有四種類型，四種類型分別是 fanout、direct、topic 、headers，不同的類型有著不同的路由策略。

5.3.2 路由鍵

RoutingKey : 路由鍵。

生產者將消息發給交換器的時候，一般會指定一個 RoutingKey ，用來指定這個消息的路由規則，而這個 RoutingKey 需要與交換器類型和綁定鍵 (BindingKey) 聯合使用才能最終生效。

在交換器類型和綁定鍵 (BindingKey) 固定的情況下，生產者可以在發送消息給交換器時，通過指定 RoutingKey 來決定消息流向哪里。

5.3.3 綁定

Binding: 綁定。RabbitMQ 中通過綁定將交換器與隊列關聯起來，在綁定的時候一般會指定一個綁定鍵(BindingKey) ，這樣 RabbitMQ 就知道如何正確地將消息路由到隊列了。

5.4 交換器類型

1).fanout : 它會把所有發送到該交換器的消息路由到所有與該交換器綁定的隊列中。

2).direct: 該類型的交換器路由規則也很簡單，它會把消息路由到那些

BindingKey 和 RoutingKey 完全匹配的隊列中。

3).topic : 前面講到 direct 類型的交換器路由規則是完全匹配 BindingKey和 RoutingKey ，但是這種嚴格的匹配方式在很多情況下不能滿足實際業務的需求。topic 類型的交換器在匹配規則上進行了擴展，它與 direct 類型的交換器相似，也是將消息路由到 BindingKey 和 RoutingKey 相匹配的隊列中，但這里的匹配規則有些不同，它約定:

RoutingKey 為一個點號"." 分割的字符串 , 如 : com.itcast.client , com.itheima.exam。

BindingKey 與 RoutingKey 一樣也是點號"." 分割的字符串。

BindingKey 中可以存在兩種特殊的字符串 "*" 和 "#" , 用于模糊匹配,其中

"#"用于匹配一個單詞, "*"用于匹配多個單個(可以是零個)。

4). headers : 該類型的交換器不依賴于路由鍵的匹配規則來路由消息，而是根據發送的消息內容中的 headers 屬性進行匹配。