序言
對比Kafka會發現, RabbtiMQ提供的功能更多,在生產者與消費者的安全性上提供了更多的控制手段.同時消息隊列的類型也比較多.竟然還有RPC的模式 所以在併發量不是很大的情況下,且對消息的安全(主要指消息的丟失)要求比較高的情況下可以使用Kafka.如有建議請騷擾:[email protected]
參考資料:https://www.cnblogs.com/williamjie/p/9481774.html
https://www.cnblogs.com/wangsen/p/11057714.html
RabbitMq組成部分
整體流程圖
直接用的同仁的圖哈
ConnectionFactory、Connection、Channel
ConnectionFactory、Connection、Channel都是RabbitMQ對外提供的API中最基本的對象。Connection是RabbitMQ的socket鏈接，它封裝了socket協議相關部分邏輯。ConnectionFactory爲Connection的製造工廠。
Channel是我們與RabbitMQ打交道的最重要的一個接口，我們大部分的業務操作是在Channel這個接口中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發佈消息等。
信道(即Channel)的原理是一條線程一條通道，多條線程多條通道同用一條TCP鏈接。一條TCP鏈接可以容納無限的信道，即使每秒成千上萬的請求也不會成爲性能的瓶頸。
Publisher
向交換器發佈消息的客戶端應用程序,即消息的生產者
Consumer
從消息隊列中取得消息的客戶端應用程序,即消息的消費者
Queue
Queue（隊列）是RabbitMQ的內部對象，用於存儲消息，用下圖表示。
RabbitMQ中的消息都只能存儲在Queue中，生產者（下圖中的P）生產消息並最終投遞到Queue中，消費者（下圖中的C）可以從Queue中獲取消息並消費。多個消費者可以訂閱同一個Queue，這時Queue中的消息會被平均分攤給多個消費者進行處理，而不是每個消費者都收到所有的消息並處理。(另外需要注意的是 生產者不是跟隊列直接相連的,中間還有個exchange,這裏省略了)
routing key
生產者在將消息發送給Exchange的時候，一般會指定一個routing key，來指定這個消息的路由規則，而這個routing key需要與Exchange Type及binding key聯合使用才能最終生效。(Exchange type 就是 exchange的路由類型, binding key就是exchange與queue綁定時的一個key,相當於給這個綁定取個名字.這個名字是跟 routing key 相同或者包含的)
Binding
RabbitMQ中通過Binding將Exchange與Queue關聯起來，這樣RabbitMQ就知道如何正確地將消息路由到指定的Queue了。
Binding key
在綁定（Binding）Exchange與Queue的同時，一般會指定一個binding key；消費者將消息發送給Exchange時，一般會指定一個routing key；當binding key與routing key相匹配時，消息將會被路由到對應的Queue中。這個將在Exchange Types章節會列舉實際的例子加以說明。
在綁定多個Queue到同一個Exchange的時候，這些Binding允許使用相同的binding key。binding key 並不是在所有情況下都生效，它依賴於Exchange Type，比如fanout類型的Exchange就會無視binding key，而是將消息路由到所有綁定到該Exchange的Queue。
Exchange
用來接收生產者發送的消息並將這些消息路由給服務器中的隊列。(根據Exchange Type來決定 怎麼分發到不同的Queue上)
Exchange Types
RabbitMQ常用的Exchange Type有fanout、direct、topic、headers這四種（AMQP規範裏還提到兩種Exchange Type，分別爲system與自定義，這裏不予以描述），下面分別進行介紹。另模式其實還有更多,但是常用的就這幾種.歡迎大家騷擾:[email protected]
1 fanout(廣播模式)
fanout類型的Exchange路由規則非常簡單，它會把所有發送到該Exchange的消息路由到所有與它綁定的Queue中。即每個Queue都會收到相同的消息.
下圖中，生產者（P）發送到Exchange（X）的所有消息都會路由到圖中的兩個Queue(兩者收到的消息都是一樣的.)，並最終被兩個消費者（C1與C2）消費。
2 direct(完全匹配模式)
direct類型的Exchange路由規則也很簡單，它會把消息路由到那些binding key與routing key完全匹配的Queue中。
如下所示:orange,black,green是 binding key. 那在此類型下,如果消息的生產者發送了routing key爲 orange的消息,則會去Q1這個隊列,如果routing key爲green 則會去Q2這個隊列
3 topic(正則匹配模式)
direct類型的Exchange路由規則是完全匹配binding key與routing key，但這種嚴格的匹配方式在很多情況下不能滿足實際業務需求。topic類型的Exchange在匹配規則上進行了擴展，它與direct類型的Exchage相似，也是將消息路由到binding key與routing key相匹配的Queue中，但這裏的匹配規則有些不同，它約定：
- routing key爲一個句點號“. ”分隔的字符串（我們將被句點號“. ”分隔開的每一段獨立的字符串稱爲一個單詞），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
- binding key與routing key一樣也是句點號“. ”分隔的字符串
- binding key中可以存在兩種特殊字符“*”與“#”，用於做模糊匹配，其中“*”用於匹配一個單詞，“#”用於匹配多個單詞（可以是零個）
如上可以看到,binding key 都變成了正則表達式. 這樣就會模糊匹配滿足條件的routing key 到指定的queue上
以上圖中的配置爲例，routingKey=”quick.orange.rabbit”的消息會同時路由到Q1與Q2，routingKey=”lazy.orange.fox”的消息會路由到Q1，routingKey=”lazy.brown.fox”的消息會路由到Q2，routingKey=”lazy.pink.rabbit”的消息會路由到Q2（只會投遞給Q2一次，雖然這個routingKey與Q2的兩個bindingKey都匹配）；routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息將會被丟棄，因爲它們沒有匹配任何bindingKey。
4 RPC
MQ本身是基於異步的消息處理，前面的示例中所有的生產者（P）將消息發送到RabbitMQ後不會知道消費者（C）處理成功或者失敗（甚至連有沒有消費者來處理這條消息都不知道）。
但實際的應用場景中，我們很可能需要一些同步處理，需要同步等待服務端將我的消息處理完成後再進行下一步處理。這相當於RPC（Remote Procedure Call，遠程過程調用）。在RabbitMQ中也支持RPC。
RabbitMQ中實現RPC的機制是：
- 客戶端發送請求（消息）時，在消息的屬性（MessageProperties，在AMQP協議中定義了14中properties，這些屬性會隨着消息一起發送）中設置兩個值replyTo（一個Queue名稱，用於告訴服務器處理完成後將通知我的消息發送到這個Queue中）和correlationId（此次請求的標識號，服務器處理完成後需要將此屬性返還，客戶端將根據這個id瞭解哪條請求被成功執行了或執行失敗）
- 服務器端收到消息並處理
- 服務器端處理完消息後，將生成一條應答消息到replyTo指定的Queue，同時帶上correlationId屬性
- 客戶端之前已訂閱replyTo指定的Queue，從中收到服務器的應答消息後，根據其中的correlationId屬性分析哪條請求被執行了，根據執行結果進行後續業務處理