一、Rabbitmq的簡單介紹
以下只是本人從零學習過程的整理
部分內容參考地址：https://www.cnblogs.com/ysocean/p/9240877.html
1、RabbitMQ的概念
RabbitMQ是實現了高階訊息佇列協議（AMQP）的開源訊息代理軟體（亦稱面向訊息的中介軟體）。
RabbitMQ伺服器是用Erlang語言編寫的，Erlang是專門為高併發而生的語言，而叢集和故障轉移是構建在開發電信平臺框架上的。所有主要的程式語言均有與代理介面通訊的客戶端庫
RabbitMQ是一個在AMQP協議標準基礎上完整的，可服用的企業訊息系統。它遵循Mozilla Public License開源協議，採用 Erlang 實現的工業級的訊息佇列(MQ)伺服器。
2、RabbitMQ的好處
A、RabbitMQ是使用Erlang語言開發的開源訊息佇列系統，基於AMQP協議來實現。
B、AMQP的主要特徵是面向訊息、佇列、路由（包括點對點和釋出/訂閱）、可靠性、安全。
C、AMQP協議更多用在企業系統內，對資料一致性、穩定性和可靠性要求很高的場景，對效能和吞吐量的要求還在其次。
D、RabbitMQ的可靠性是非常好的，資料能夠保證百分之百的不丟失。可以使用映象佇列，它的穩定性非常好。所以說在我們網際網路的金融行業。
E、對資料的穩定性和可靠性要求都非常高的情況下，我們都會選擇RabbitMQ。當然沒有kafka效能好，但是要比AvtiveMQ效能要好很多。也可以自己做一些效能的優化。
F、RabbitMQ可以構建異地雙活架構，包括每一個節點儲存方式可以採用磁碟或者記憶體的方式
3、RabbitMq的使用場景
3.1什麼時候使用MQ？
1）資料驅動的任務依賴
2）上游不關心多下游執行結果
3）非同步返回執行時間長
3.2什麼時候不使用MQ？
需要實時關注執行結果 （eg：同步呼叫）
4、RabbitMQ的幾種工作模式
4.1、簡單模式（Simple）
簡單的傳送與接收，沒有特別的處理
4.2、工作模式（Work）
單傳送多接收，一個生產者端，多個消費者端。示例中為了保證訊息傳送的可靠性，不丟失訊息，使訊息持久化了。同時為了防止接收端在處理訊息時down掉，只有在訊息處理完成後才傳送訊息確認
4.3、釋出訂閱模式（Publish/Subscribe）
釋出、訂閱模式，生產者端傳送訊息，多個消費者同時接收所有的訊息
4.4、路由模式（Routing）
生產者按routing key傳送訊息，不同的消費者端按不同的routing key接收訊息
4.5、萬用字元（或主題）模式（Topics ，按topic傳送接收)
生產者端不只按固定的routing key傳送訊息，而是按字串“匹配”傳送，消費者端同樣如此。
與之前的路由模式相比，它將資訊的傳輸型別的key更加細化，以“key1.key2.keyN…”的模式來指定資訊傳輸的key的大型別和大型別下面的小型別，讓消費者端可以更加精細的確認自己想要獲取的資訊型別。而在消費者端，不用精確的指定具體到哪一個大型別下的小型別的key，而是可以使用類似正則表示式(但與正則表示式規則完全不同)的萬用字元在指定一定範圍或符合某一個字串匹配規則的key，來獲取想要的資訊。“萬用字元交換機”（Topic Exchange）將路由鍵和某模式進行匹配。此時佇列需要繫結在一個模式上。符號“#”匹配一個或多個詞，符號“*”僅匹配一個詞。
4.6、死信佇列
描述：Q1佇列綁定了x-dead-letter-exchange(死信交換機)為X2，x-dead-letter-routing-key（死信路由key)指向Q2(佇列2)
P(生產者)傳送訊息經X1(交換機1)路由到Q1(佇列1)，Q1的訊息觸發特定情況，自動把訊息經X2(交換機2)路由到Q2(佇列2)，C(消費者)直接訊息Q2的訊息。
特定情況有哪些呢：
- 訊息被拒(basic.reject or basic.nack)並且沒有重新入隊(requeue=false)；
- 當前佇列中的訊息數量已經超過最大長度(建立佇列時指定" x-max-length引數設定佇列最大訊息數量)。
- 訊息在佇列中過期，即當前訊息在佇列中的存活時間已經超過了預先設定的TTL(Time To Live)時間；
4.7、延時佇列
延時佇列其實也是配合死信佇列一起用，其實就是上面死信佇列的第二中情況。給佇列新增訊息過時時間（TTL），變成延時佇列。
簡單的描述就是：P(生產者)傳送訊息到Q1(延時佇列)，Q1的訊息有過期時間，比如10s，那10s後訊息過期就會觸發死信，從而把訊息轉發到Q2（死信佇列）。
解決問題場景：像商城下單，未支付時取消訂單場景。下單時寫一條記錄入Q1,延時30分鐘後轉到Q2，消費Q2，檢查訂單，支付則不做操作，沒支付則取消訂單，恢復庫存。
延時佇列還可以設定不同的過期時間
5、訊息通訊的概念
Rabbitmq訊息通訊的過程：
5.1、生產者和消費者
在 RabbitMQ 的通訊過程中，有兩個主要的角色：生產者和消費者。類比於郵件通訊的傳送方和接收方。
這裡首先我們要明確 RabbtiMQ 伺服器是不能夠產生資料的，正如同其名字——訊息中介軟體，是一個用來傳遞訊息的中間商。生產者產生建立訊息，然後釋出到代理伺服器（RabbitMQ），而消費者則從代理伺服器獲取訊息（不是直接找生產者要訊息），而且在實際應用中，生產者和消費者也是可以角色互相轉換的，所以當我們應用程式連線到 RabbitMQ 伺服器時，必須要明確我是生產者呢還是消費者。
5.2、訊息
生產者建立訊息，然後釋出到 RabbitMQ 伺服器中，那麼什麼是訊息？
這裡的訊息分為兩部分：有效內容和內容標籤。
①、有效內容：可以是任何內容，一個數組，一個集合，甚至二進位制資料都可以。RabbitMQ 不會在意你發什麼資料，儘管發就行了。
②、內容標籤：描述有效內容，是 RabbitMQ 用來決定誰將獲得訊息。前面說的郵件通訊，必須明確指定傳送方地址和收件方地址，而基於 AMQP 協議的 RabbitMQ 則是通過生產者傳送訊息附帶的內容標籤將訊息傳送個感興趣的消費者。
注意最上面的大圖，一般來說生產者建立訊息會設定標籤，但是傳輸到消費者那裡就沒有標籤了，除非你在有效內容中說明誰是生產者，一般消費者是不知道誰產生的訊息的。
5.3、通道
生產者產生了訊息，然後釋出到 RabbitMQ 伺服器，釋出之前肯定要先連線上伺服器，也就是要在應用程式和rabbitmq 伺服器之間建立一條 TCP 連線，一旦連線建立，應用程式就可以建立一條 AMQP 通道。
通道是建立在“真實的”TCP 連線內的虛擬連線，AMQP 命令都是通過通道傳送出去的，每條通道都會被指派一個唯一的ID（AMQP庫會幫你記住ID的），不論是釋出訊息、訂閱佇列或者接收訊息，這些動作都是通過通道來完成的。
可能有人會問，為什麼不直接通過 TCP 連線來發送AMQP命令呢？
這裡原因是效率問題，因為對於作業系統來說，每次建立和銷燬 TCP 會話是非常昂貴的開銷，而實際系統中，比如電商雙十一，每秒鐘高峰期成千上萬條連線，一般來說作業系統建立TCP連線是有數量限制的，那麼這就會遇到瓶頸。
引入通道的概念，我們可以在一條 TCP 連線上建立 N多個通道，這樣既能傳送命令，也能夠保證每條通道的私密性，我們可以將其想象為光纖電纜。
5.4、交換器和佇列
擷取上面的一部分圖：
交換器和佇列都是 RabbitMQ 伺服器的一部分，我們知道生產者會將訊息傳送到 RabbitMQ 伺服器，而進入該伺服器後，首先進入交換機部分，然後由交換器根據訊息附帶的內容標籤，將訊息繫結到相應的佇列。我們首先來看什麼是佇列：
①、容納訊息的場所，生產者傳送到RabbitMQ伺服器的訊息會在佇列中等待消費者消費。
②、佇列是 RabbitMQ 伺服器中最後的終點（除非訊息進入了黑洞，黑洞的概念下面會介紹）。
③、佇列可以實現負載均衡，我們可以增加一堆消費者，然後讓 RabbitMQ 以迴圈的方式來均勻的分配訊息。
搞清楚了佇列是什麼了，那麼訊息是如何到達佇列的呢？沒錯，就是通過交換器。
訊息進入RabbitMQ 伺服器時，會首先將訊息傳送到交換器，然後交換器會根據特定的路由演算法以及訊息的內容標籤將訊息繫結到相應的佇列。在 AMQP 協議中有四種交換器：direct、fanout、topic和 headers，每種交換器都實現了不同的路由演算法，這也對應 RabbitMQ 工作的幾種不同方式，這是重點，後面部落格會進行詳細介紹。
5.5、虛擬主機
最上面那張大圖，畫了虛擬主機A以及虛擬主機B，說明在 RabbitMQ 伺服器中存在著多個虛擬主機，那麼虛擬主機到底是什麼？
首先我們丟擲這樣一個問題，一個 RabbitMQ 肯定不是隻服務一個應用程式，那麼多個應用程式同時使用 RabbitMQ 伺服器，如何保證彼此之間不會衝突？
答案就是使用虛擬主機，虛擬主機其實就是一個迷你版的RabbitMQ 伺服器，它擁有自己的交換器和佇列，更重要的是虛擬主機擁有自己的許可權機制，一個伺服器能夠建立多個虛擬主機。那麼我們在使用RabbitMQ伺服器的時候，只需要將一個應用程式對應一個虛擬主機，這種各個例項間邏輯上的分離就能夠保證不同的應用程式安全的傳遞訊息。
預設的虛擬主機是“/”。
本文來自部落格園，作者：yangleiyu，轉載請註明原文連結：https://www.cnblogs.com/yangleiyu/p/15232941.html