一、什么是MQ？

MQ是message queue的縮寫,本質上是個佇列，FIFO先入先出原則，佇列中存放的是message，是一種跨行程的通信機制，用于上下游傳遞資訊，在互聯網程式架構中，MQ是一種非常常見的上下游“邏輯解耦+物理解耦”的訊息通信服務，使用了MQ以后，訊息發送只需要依賴MQ，不用依賴于其他服務，

二、為什么要用MQ？

（一）流量消鋒

如果我們的訂單系統最多能夠處理掉一萬次訂單，這個處理能力應付正常時段的下單是搓搓有余了，但是如果在高峰期，比如淘寶的雙11活動，有超過一萬次的下單操作，系統則是處理不了的，需要做出相應的限制機制，那么如果我們使用訊息佇列作為緩沖，我們可以取消這個限制，將一秒內下的訂單分散成一段時間來處理，這時有些用戶可能在下單十幾秒后才能收到下單成功的操作，但是比起限制下單的體驗要好得多，

（二）應用解耦

以電商為例，應用中由訂單系統、庫存系統、訊息系統、支付系統等等，在用戶創建訂單以后，如果耦合的如上系統任何一個出現了故障，那么將導致下單功能例外，但是如果轉變成訊息佇列的方式后，各個模塊之間的依賴問題就會減少很多，比如如果下單的時候，訊息系統出現了問題，需要一定的時間來修復，雖然訊息系統出現了問題，但是其他模塊是依舊可執行的，而訊息系統需要發送的訊息依舊存盤在訊息佇列中，當訊息系統修復好時，依舊可以成功發出對應的訊息，

（三）異步處理

在傳統模式中，訂單系統呼叫支付系統，需要等待支付系統執行完畢后，回傳執行結果，然后再進行支付系統的下一步操作，耦合度極高，但是使用訊息佇列，就可以解決這個問題，當訂單系統呼叫支付系統后，支付系統開始執行，此時訂單系統以后可以執行其他操作，當支付系統執行完畢后，會將回傳結果放進訊息佇列中，再由訊息佇列轉發給訂單系統，

三、MQ的分類

（一）ActiveMQ

單機吞吐量萬級，時效性ms級，可用性高，基于主從架構實作高可用性，訊息可靠性較低的概率丟失資料，高吞吐量場景的使用較少，

（二）Kafka

為大資料而生的訊息中間件，百萬級TPS的吞吐量，再資料采集、傳輸、存盤的程序中發揮著聚聚輕重的作用，單機寫入TPS約在百萬條/秒，最大的優點就是吞吐量高，時效性ms級，分布式，一個資料有多個副本，少數機器宕機不會丟失資料，不會導致不可用，消費者采用Pull的方式獲取訊息，訊息有序，有Kafaka Web管理界面kafka-Manager，日志領域比較成熟，在大資料領域實時計算以及日志采集被大規模使用，
但是Kafka單機超過64個佇列/磁區，Load會發生明顯的超高現象，佇列越多，Load越高，發送訊息的回應時間越長，使用短輪詢的方式，實時性取決于短輪詢的時間間隔，消費失敗不支持重試，支持消費的順序，但是一臺代理宕機以后，就會產生訊息亂序，

（三）RocketMQ

RocketMQ是出自阿里巴巴的開源產品，用JAVA語言實作，設計時參考的Kafka，并作出了一些改進，被阿里巴巴廣泛應用在訂單、交易、充值、流計算、訊息推送、日志流式處理、binglog分發等場景，在阿里雙11的活動中經歷了多次考驗，性能極佳，
單機吞吐量十萬級，可用性高，分布式架構，訊息可以做到0丟失，MQ功能較為完善，擴展性好，支持十億級別的訊息堆積，不會應為堆積導致性能下降，

（四）RabbitMQ

于2007年發布，是一個在AMQP（高級訊息佇列協議）基礎上完成的，可復用的企業訊息系統，是當前最主流的訊息中間件之一，
使用erlang語言實作，由于其語言的高并發特性，性能較好，吞吐量萬級，MQ功能計較完善，穩定易用跨平臺，支持多種語言，

四、RabbitMQ

RabbitMQ是一個訊息中間件，它接收并轉達訊息，將訊息存盤在RabbitMQ中，等待需要的服務去其中取對應的訊息，主要用于訊息的接收、存盤以及轉發，

（一）RabbitMQ后臺管理界面

本文主要講解RabbitMQ，它的安裝在這里我們就不做過多介紹，網上一搜有很多教程，首先要下載erlang，配置好環境變數，然后下載RabbitMQ，配置好環境變數，配置完成后，啟動sbin目錄下的rabbitmq-server.bat，成功運行后，我們訪問http://localhost:15672即可進入到管理界面，我們來看看它的管理界面：

（二）RabbitMQ的四大核心概念

1.生產者

產生資料時發送訊息的角色，

2.交換機

一方面用來接收來自生產者的訊息，另一方面它將訊息推送到佇列中，交換機必須確切地知道如何處理它接收地訊息，是將訊息丟棄還是推送到特定的佇列，由交換機決定，

3.佇列

佇列是RabbitMQ內部使用的一種資料結構，盡管訊息流經RabbitMQ和應用程式，但是他們只能存盤在佇列中，生產者將訊息發送到一個佇列，消費者就可以嘗試從一個佇列中接收資料，

4.消費者

消費者是一個等待接收訊息的程式，生產者消費者和訊息中間件大多時候不在同一機器上，同一個應用程式可以是生產者也可以是消費者，

（三）RabbitMQ的核心部分

1.RabbitMQ的六大模式

一、簡單模式
二、作業模式
三、發布/訂閱模式
四、路由模式
五、主題模式
六、發布/確認模式

2.RabbitMQ中的各名詞介紹

①RabbitMQ作業原理

②Broker

接收和分發訊息的應用，RabbitMQ Server就是Message Broker，

③Virtual host

當多個不同的用戶使用同一個RabbitMQ Server提供服務時，可以劃分出多個vhost,每個用戶在自己的vhost創建exchange/queue等，類似于網路中的namespace概念，

④Connection

publisher / consumer 和 broker之間的TCP連接，

⑤Channel

如果我們每一次訪問RabbitMQ都建立一個Connection，那么在訊息大量建立TCP Connection的開銷將是巨大的，效率也很低，Channel實在connection內部建立的邏輯連接，如果應用程式支持多執行緒，通常每個thread創建單獨的channel進行通訊，channel有一個channel id，幫助客戶端進和message broker識別channel，所以channel之間是完全隔離的，Channel作為輕量級的Connection極大減少了作業系統建立TCP connection的開銷，

⑥Exchange

message到達broker的第一站，根據分發規則，匹配拆線呢表中的routing key，分發訊息到queue中去，常見的交換機型別有：direct(point-to-point)直接交換機、topic(publish-subscribe)主題交換機、fanout(multicast)扇出交換機，

⑦Queue

訊息最終被推送到這里等待消費者取走消費，

⑧Binding

exchange和queue之間的虛擬連接，binding中可以包含routing key，Binding資訊被保存到exchange中的查詢表中，用于message的分發資料，

3.死信佇列

死信就是無法被消費的訊息，一般來講生產者將訊息投遞到Broker中以后就直接到佇列里去了，然后消費者再從佇列中取訊息，但是在某些應用的特殊業務場景下，一些特殊的原因導致了佇列中的某些訊息無法被消費，這樣的訊息如果我們沒有對其進行處理，就變成了死信，進而形成了死心佇列，

為了保證資料不丟失，需要我們使用RabbitMQ的死信佇列機制，當訊息發生例外時，將訊息存入死信佇列中，等后續能夠消費的時候再將訊息從佇列中拿出來消費，像下單成功以后在指定的時間內沒有付款時，自動失效，

死信的來源：
一、訊息TTL（存活時間）過期
二、佇列達到最大長度，佇列已經滿了，無法再添加資料到佇列中，
三、訊息被拒絕（basic.reject 或 basic.nack）并且requeue=false

4.延遲佇列

延遲佇列的內部是有序的，最重要的就是它的演示屬性了，演示佇列中的元素就是希望在指定的時間到了以后才開始對訊息進行處理，簡單來說，演示佇列就是用來存放需要在指定時間被處理的元素的佇列，比如說訂單在十分鐘內未支付自動取消訂單，比如說用戶注冊成功以后三天內沒有登錄我們就進行短信提醒，