1、官方文檔
https://www.rabbitmq.com/admin-guide.html
2、AMQP 0-9-1 模型解釋
生産者：産生資料發送消息的程式。
交換機：是 RabbitMQ 非常重要的一個部件，一方面它接收來自生産者的消息，另一方面它将消息推送到隊列中。交換機必須确切知道如何處理它接收到的消息，是将這些消息推送到特定隊列還是推送到多個隊列，亦或者是把消息丢棄，這個得有交換機類型決定。
隊列：隊列是 RabbitMQ 内部使用的一種資料結構，盡管消息流經 RabbitMQ 和應用程式一樣，但它們隻能存儲在隊列中。隊列僅受主機的記憶體和磁盤限制的限制，本質上是一個大的消息緩沖區。許多生産者可以将消息發送到一個隊列，許多消費者可以嘗試從一個隊列接收資料。
惰性隊列：https://www.rabbitmq.com/lazy-queues.html；
消費者：大多數時候是一個等待接收消息的程式。請注意生産者，消費者和消息中間件很多時候并不在同一機器上。同一個應用程式既可以是生産者又可以是消費者。
模型解釋文檔 https://www.rabbitmq.com/tutorials/amqp-concepts.html
釋出者文檔 https://www.rabbitmq.com/publishers.html
消費者 https://www.rabbitmq.com/consumers.html
隊列 https://www.rabbitmq.com/queues.html
協定擴充 https://www.rabbitmq.com/extensions.html
3、工作原理
Broker：接收和分發消息的應用， RabbitMQ Server 就是 Message Broker
Virtual host：出于多租戶和安全因素設計的，把 AMQP 的基本元件劃分到一個虛拟的分組中，類似
于網絡中的 namespace 概念。當多個不同的使用者使用同一個 RabbitMQ server 提供的服務時，可以劃分出多個 vhost，每個使用者在自己的 vhost 建立 exchange／ queue 等
Connection： publisher／ consumer 和 broker 之間的 TCP 連接配接
https://www.rabbitmq.com/connections.html 涉及mq性能調優。
Channel：如果每一次通路 RabbitMQ 都建立一個 Connection，在消息量大的時候建立 TCP
Connection 的開銷将是巨大的，效率也較低。 Channel 是在 connection 内部建立的邏輯連接配接，如果應用程式支援多線程，通常每個 thread 建立單獨的 channel 進行通訊， AMQP method 包含了 channel id 幫助客
戶端和 message broker 識别 channel，是以 channel 之間是完全隔離的。 Channel 作為輕量級的Connection 極大減少了作業系統建立 TCP connection 的開銷
https://www.rabbitmq.com/channels.html
Exchange： message 到達 broker 的第一站，根據分發規則，比對查詢表中的 routing key，分發
消息到 queue 中去。常用的類型有： direct (point-to-point), topic (publish-subscribe) and fanout(multicast)
Queue： 消息最終被送到這裡等待 consumer 取走
https://www.rabbitmq.com/queues.html
Binding： exchange 和 queue 之間的虛拟連接配接， binding 中可以包含 routing key， Binding 資訊被儲存到 exchange 中的查詢表中，用于 message 的分發依據
https://www.rabbitmq.com/tutorials/amqp-concepts.html google翻譯成中文不妨礙閱讀
4、業務用途
4.1、應用解耦
解決多個系統鍊式調用耦合導緻整個業務失敗的情況。解決多個系統鍊式調用耦合導緻整個業務失敗的情況。
4.2、異步處理
4.3、流量削峰
4.4、監控
文檔 https://www.rabbitmq.com/monitoring.html
5、性能調優
https://www.rabbitmq.com/runtime.html
6、MQ擴充
https://www.rabbitmq.com/extensions.html
6.1、持久化
從記憶體持久化消息到硬碟(生産者)，再從硬碟加載到記憶體（消費者）。
6.2、不公平分發
RabbitMQ預設是輪訓分發模式，就是兩個消費者輪流接受消息，但是這種模式在某些場景下是不恰當的，如果其中一個消費者執行的時間很長，而消息的産生有很快，就會導緻大量消息的堆積，效率很低，是不科學的
為了避免上述情況的出現，我們應使用不公平分發（能者多勞）
//設定為不公平分發
/* * 0：預設，表示輪訓分發 * 1：表示不公平分發 **/
channel.basicQos(1); 6.3、預取值
該值定義通道上允許的未确認消息的最大數量，一旦數量達到配置的數量， RabbitMQ 将停止在通道上傳遞更多消息，除非至少有一個未處理的消息被确認
也就是說,定義一個信道上的最大數量是5，則信道中最多隻能有5個待消費的消息
/** 0：預設，表示輪訓分發* 1：表示不公平分發* 大于2：表示預取值**/
channel.basicQos(5);//表示最大隻能有5個待處理的消息 6.4、釋出确認
生産者将信道設定成 confirm 模式，一旦信道進入 confirm 模式，所有在該信道上面釋出的 消息都将會被指派一個唯一的 ID(從 1 開始)，使生産者知道消息已經正确到達目的隊列，
如果消息和隊列是可持久化的，那麼确認消息會在将消息寫入磁盤之後發出0
confirm 模式最大的好處在于他是異步的，一旦釋出一條消息，生産者應用程式就可以在等信 道傳回确認的同時繼續發送下一條消息，當消息最終得到确認之後，生産者應用便可以通過回調 方法來處理該确認消息，如果 RabbitMQ 因為自身内部錯誤導緻消息丢失，就會發送一條 nack 消 息，生産者應用程式同樣可以在回調方法中處理該 nack 消息。
代碼示例 https://www.jianshu.com/p/2c5eebfd0e95
錯誤示例