釋義：
MQ （message queue ）又稱消息隊列，也叫消息中間件，是遵守JMS（java message service）規范的一種軟件。隊列我們可以理解為管道。以管道的方式做消息傳遞。
(同時還有另一個叫AMQP的應用層協議，語言無關性不受產品 語言等限制，rabbitMQ支持這個 )是類似於數據庫一樣需要獨立部署在服務器上的一種應用，提供接口給其他系統調用。
主要用於各個系統之間通信的解耦。
場景：
1.其實我們在雙11的時候，當我們凌晨大量的秒殺和搶購商品，然后去結算的時候，就會發現，界面會提醒我們，讓我們稍等，以及一些友好的圖片文字提醒。而不是像前幾年的時代，動不動就頁面卡死，報錯等來呈現給用戶。
在這業務場景中，我們就可以采用隊列的機制來處理，因為同時結算就只能達到這么多。
2.在我們平時的超市中購物也是一樣，當我們在結算的時候，並不會一窩蜂一樣涌入收銀台，而是排隊結算。這也是隊列機制。
對，就是排隊。一個接着一個的處理，不能插隊。
RabbitMQ簡介
AMQP，即Advanced Message Queuing Protocol，高級消息隊列協議，是應用層協議的一個開放標准，為面向消息的中間件設計。消息中間件主要用於組件之間的解耦，消息的發送者無需知道消息使用者的存在，反之亦然。 AMQP的主要特征是面向消息、隊列、路由（包括點對點和發布/訂閱）、可靠性、安全。 RabbitMQ是一個開源的AMQP實現，服務器端用Erlang語言編寫，支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。 下面將重點介紹RabbitMQ中的一些基礎概念，了解了這些概念，是使用好RabbitMQ的基礎。
ConnectionFactory、Connection、Channel
ConnectionFactory、Connection、Channel都是RabbitMQ對外提供的API中最基本的對象。Connection是RabbitMQ的socket鏈接，它封裝了socket協議相關部分邏輯。ConnectionFactory為Connection的制造工廠。 Channel是我們與RabbitMQ打交道的最重要的一個接口，我們大部分的業務操作是在Channel這個接口中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發布消息等。
Queue
Queue（隊列）是RabbitMQ的內部對象，用於存儲消息，用下圖表示。
38-20190617112409949-104238272.png)
RabbitMQ中的消息都只能存儲在Queue中，生產者（下圖中的P）生產消息並最終投遞到Queue中，消費者（下圖中的C）可以從Queue中獲取消息並消費。
多個消費者可以訂閱同一個Queue，這時Queue中的消息會被平均分攤給多個消費者進行處理，而不是每個消費者都收到所有的消息並處理。
Message acknowledgment
在實際應用中，可能會發生消費者收到Queue中的消息，但沒有處理完成就宕機（或出現其他意外）的情況，這種情況下就可能會導致消息丟失。為了避免這種情況發生，我們可以要求消費者在消費完消息后發送一個回執給RabbitMQ，RabbitMQ收到消息回執（Message acknowledgment）后才將該消息從Queue中移除；如果RabbitMQ沒有收到回執並檢測到消費者的RabbitMQ連接斷開，則RabbitMQ會將該消息發送給其他消費者（如果存在多個消費者）進行處理。這里不存在timeout概念，一個消費者處理消息時間再長也不會導致該消息被發送給其他消費者，除非它的RabbitMQ連接斷開。 這里會產生另外一個問題，如果我們的開發人員在處理完業務邏輯后，忘記發送回執給RabbitMQ，這將會導致嚴重的bug——Queue中堆積的消息會越來越多；消費者重啟后會重復消費這些消息並重復執行業務邏輯…
另外pub message是沒有ack的。
Message durability
如果我們希望即使在RabbitMQ服務重啟的情況下，也不會丟失消息，我們可以將Queue與Message都設置為可持久化的（durable），這樣可以保證絕大部分情況下我們的RabbitMQ消息不會丟失。但依然解決不了小概率丟失事件的發生（比如RabbitMQ服務器已經接收到生產者的消息，但還沒來得及持久化該消息時RabbitMQ服務器就斷電了），如果我們需要對這種小概率事件也要管理起來，那么我們要用到事務。由於這里僅為RabbitMQ的簡單介紹，所以這里將不講解RabbitMQ相關的事務。
Prefetch count
前面我們講到如果有多個消費者同時訂閱同一個Queue中的消息，Queue中的消息會被平攤給多個消費者。這時如果每個消息的處理時間不同，就有可能會導致某些消費者一直在忙，而另外一些消費者很快就處理完手頭工作並一直空閑的情況。我們可以通過設置prefetchCount來限制Queue每次發送給每個消費者的消息數，比如我們設置prefetchCount=1，則Queue每次給每個消費者發送一條消息；消費者處理完這條消息后Queue會再給該消費者發送一條消息。
