目錄
一、MQ概述
二、MQ的優劣勢
1、優勢
（1）應用解耦
（2）異步提速
（3）削峰填谷
2、劣勢
（1）系統可用性降低
（2）系統複雜度提高
三、RabbitMQ基本概念
1、RabbitMQ簡介
2、RabbitMQ的相關概念
一、MQ概述
MQ全程 Message Queue（消息隊列），實在消息的傳輸過程中儲存消息的容器。多用于分布式系統之間進行通信。
二、MQ的優劣勢
1、優勢
（1）應用解耦
就以電商下單為例子：在分布式場景下原始的下單邏輯
使用者下單，訂單系統會和其餘的各個系統互動，比如庫存系統，支付系統等等系統。但是如果現在庫存系統挂了，那麼訂單系統也會受到影響，那麼就會導緻相應的一些業務闆塊受到影響。如果還需要加入其餘的系統進來，還需要去修改訂單系統的代碼，這樣可維護性也很低。
也就是說：系統的耦合性越高，容錯性越低，可維護性就越底。
使用MQ過後的下單邏輯：
加入MQ過後，訂單系統的資料就隻需要放到MQ中去，庫存等其他系統也隻需要去MQ中取資料即可。比如庫存系統挂了的話，對于其它系統是沒有影響的。如果新加一個系統的話也和訂單系統沒有直接的關系，是跟MQ互動了。
使用MQ使得應用間解耦，提升容錯性和可維護性。
（2）異步提速
沒有加MQ之前：
一個訂單操作耗時：20+300+300+300 = 920ms
使用者點選完下單按鈕後，需要等待920ms才能得到下單響應，太慢了。
添加MQ之後：
由于MQ的性能是很優越的，系統與MQ之間的互動時間遠小于系統與系統之間的互動時間。
由于訂單系統和庫存等其它系統是沒有直接互動的，訂單系統隻要把資料交給MQ後就算下單完成了。
使用者點選下單按鈕後，隻需要等待25ms就能得到下單響應（20 + 5 = 25ms）。
提升使用者體驗和系統吞吐量（機關時間内處理請求的數目）。
（3）削峰填谷
使用者下單直接與訂單系統互動的時候，假設是秒殺，每秒鐘有5000個請求直接打到訂單系統中，如果訂單系統每秒鐘最大請求是1000，這樣必定會把系統直接打挂掉。
請求資料直接和MQ互動，訂單系統每秒直接從MQ中拉取1000個請求，這樣就可以讓系統更好的處理自己的最大請求數。
使用了 MQ 之後，限制消費消息的速度為1000，這樣一來，高峰期産生的資料勢必會被積壓在 MQ 中，高峰就被“削”掉了，但是因為消息積壓，在高峰期過後的一段時間内，消費消息的速度還是會維持在1000，直到消費完積壓的消息，這就叫做“填谷”。
使用MQ後，可以提高系統穩定性。
MQ的優勢：
- 應用解耦：提高系統容錯性和可維護性。
- 異步提速：提升使用者體驗和系統吞吐量。
- 削峰填谷：提高系統穩定性
2、劣勢
（1）系統可用性降低
系統引入的外部依賴越多，系統穩定性越差。一旦MQ當機，就會對業務造成影響。
這裡就需要使用的MQ的高可用來解決這個問題。
（2）系統複雜度提高
MQ的加入大大增加了系統的複雜度，以前系統間是同步的遠端調用，現在是通過MQ進行異步調用。
這裡就需要考慮到如何保證消息不被丢失等情況？
常見的MQ産品對比：
| RabbitMQ | ActiveMQ | RocketMQ | Kafka | |
| 公司/社群 | Rabbit | Apache | 阿裡 | Apache |
| 開發語言 | Erlang | Java | Java | Scala&Java |
| 協定支援 | AMQP，XMPP，SMTP，STOMP | OpenWire,STOMP，REST,XMPP,AMQP | 自定義 | 自定義協定，社群封裝了http協定支援 |
| 用戶端支援語言 | 官方支援Erlang，Java，Ruby等,社群産出多種API，幾乎支援所有語言 | Java，C，C++，Python，PHP，Perl，.net等 | Java，C++（不成熟） | 官方支援Java,社群産出多種API，如PHP，Python等 |
| 單機吞吐量 | 萬級（其次） | 萬級（最差） | 十萬級（最好） | 十萬級（次之） |
| 消息延遲 | 微妙級 | 毫秒級 | 毫秒級 | 毫秒以内 |
| 功能特性 | 并發能力強，性能極其好，延時低，社群活躍，管理界面豐富 | 老牌産品，成熟度高，文檔較多 | MQ功能比較完備，擴充性佳 | 隻支援主要的MQ功能，畢竟是為大資料領域準備的。 |
三、RabbitMQ基本概念
1、RabbitMQ簡介
AMQP，即 Advanced Message Queuing Protocol（進階消息隊列協定），是一個網絡協定，是應用層協定的一個開放标準，為面向消息的中間件設計。基于此協定的用戶端與消息中間件可傳遞消息，并不受用戶端/中間件不同産品，不同的開發語言等條件的限制。2006年，AMQP 規範釋出。類比HTTP。
Rabbitmq官網：https://www.rabbitmq.com/
RabbitMQ基礎架構如下圖：
2、RabbitMQ的相關概念
- Broker：接收和分發消息的應用，RabbitMQ Server 就是 Message Broker。
- Virtual Host：出于多租戶和安全因素設計的，把 AMQP 的基本元件劃分到一個虛拟的分組中，類似于網絡中的 namespace 概念。當多個不同的使用者使用同一個 RabbitMQ Server提供的服務時，可以劃分出多個 vhost ，每個使用者在自己的 vhost 建立 exchange / queue 等。
- Connection：如果每一次通路 RabbitMQ 都建立一個 connection，在消息量大的時候建立 TCP Connection 的開銷将是巨大的，效率也很低。Channel 是在 Connection 内部建立的邏輯連結，如果應用程式支援多線程，通常每個 thread 建立單獨的 channel 進行通訊，AMQP method 包含了 channel id 幫助用戶端和 message broker 識别 channel，是以 chnnel 之間是完全隔離的。Channel 作為輕量級的 Connetion 極大減少了作業系統建立 TCP Connection 的開銷。
- Exchange：message 到達 broker 的第一站，根據分發規則，比對查詢表中的 routing key，分發消息到 queue 中去。常用的類型有：direct(point-to-point)，topic(publish-subscribe)，fanout(multicast)。
- Queue：消息最終被送到這裡等待 consumer 取走。
- Binding：exchange 和 queue 之間的虛拟連接配接，binding 中可以包含 routing key。Binding 資訊被儲存到 exchange 中的查詢表中，用于 message 的分發依據。