rabbitMQ的消息模型

基本消息模型官方介紹：

RabbitMQ是一個消息代理：它接受和轉發消息。 你能夠把它想象成一個郵局：當你把郵件放在郵箱裏時，你能夠肯定郵差先生最終會把郵件發送給你的收件人。 在這個比喻中，RabbitMQ是郵政信箱，郵局和郵遞員。
RabbitMQ與郵局的主要區別是它不處理紙張，而是接受，存儲和轉發數據消息的二進制數據塊。

P（producer/ publisher）：生產者，一個發送消息的用戶應用程序。
C（consumer）：消費者，消費和接收有相似的意思，消費者是一個主要用來等待接收消息的用戶應用程序
隊列（紅色區域）：rabbitmq內部相似於郵箱的一個概念。雖然消息流經rabbitmq和你的應用程序，可是它們只能存儲在隊列中。隊列只受主機的內存和磁盤限制，實質上是一個大的消息緩衝區。許多生產者能夠發送消息到一個隊列，許多消費者能夠嘗試從一個隊列接收數據。
總之：
生產者將消息發送到隊列，消費者從隊列中獲取消息，隊列是存儲消息的緩衝區。

咱們將用Java編寫兩個程序;發送單個消息的生產者，以及接收消息並將其打印出來的消費者。咱們將詳細介紹Java API中的一些細節，這是一個消息傳遞的「Hello World」。
咱們將調用咱們的消息發佈者（發送者）Send和咱們的消息消費者（接收者）Recv。發佈者將鏈接到RabbitMQ，發送一條消息，而後退出。
work消息模型工做隊列或者競爭消費者模式

在第一篇教程中，咱們編寫了一個程序，從一個命名隊列中發送並接受消息。在這裏，咱們將建立一個工做隊列，在多個工做者之間分配耗時任務。
工做隊列，又稱任務隊列。主要思想就是避免執行資源密集型任務時，必須等待它執行完成。相反咱們稍後完成任務，咱們將任務封裝爲消息並將其發送到隊列。 在後臺運行的工做進程將獲取任務並最終執行做業。當你運行許多消費者時，任務將在他們之間共享，可是一個消息只能被一個消費者獲取。
這個概念在Web應用程序中特別有用，由於在短的HTTP請求窗口中沒法處理複雜的任務。
接下來咱們來模擬這個流程：
P：生產者：任務的發佈者C1：消費者，領取任務而且完成任務，假設完成速度較快C2：消費者2：領取任務並完成任務，假設完成速度慢
訂閱模型分類
在以前的模式中，咱們建立了一個工做隊列。 工做隊列背後的假設是：每一個任務只被傳遞給一個工做人員。 在這一部分，咱們將作一些徹底不一樣的事情 - 咱們將會傳遞一個信息給多個消費者。 這種模式被稱爲「發佈/訂閱」。
訂閱模型示意圖：

解讀：
一、1個生產者，多個消費者
二、每個消費者都有本身的一個隊列
三、生產者沒有將消息直接發送到隊列，而是發送到了交換機
四、每一個隊列都要綁定到交換機
五、生產者發送的消息，通過交換機到達隊列，實現一個消息被多個消費者獲取的目的
X（Exchanges）：交換機一方面：接收生產者發送的消息。另外一方面：知道如何處理消息，例如遞交給某個特別隊列、遞交給全部隊列、或是將消息丟棄。到底如何操做，取決於Exchange的類型。
Exchange類型有如下幾種：
Fanout：廣播，將消息交給全部綁定到交換機的隊列
​
Direct：定向，把消息交給符合指定routing key 的隊列
​
Topic：通配符，把消息交給符合routing pattern（路由模式） 的隊列
咱們這裏先學習
Fanout：即廣播模式
Exchange（交換機）只負責轉發消息，不具有存儲消息的能力，所以若是沒有任何隊列與Exchange綁定，或者沒有符合路由規則的隊列，那麼消息會丟失！
訂閱模型-Fanout
Fanout，也稱爲廣播。
流程圖：

在廣播模式下，消息發送流程是這樣的：
1） 能夠有多個消費者
2） 每一個消費者有本身的queue（隊列）
3） 每一個隊列都要綁定到Exchange（交換機）
4） 生產者發送的消息，只能發送到交換機，交換機來決定要發給哪一個隊列，生產者沒法決定。
5） 交換機把消息發送給綁定過的全部隊列
6） 隊列的消費者都能拿到消息。實現一條消息被多個消費者消費
訂閱模型-Direct
有選擇性的接收消息
在訂閱模式中，生產者發佈消息，全部消費者均可以獲取全部消息。
在路由模式中，咱們將添加一個功能 - 咱們將只能訂閱一部分消息。 例如，咱們只能將重要的錯誤消息引導到日誌文件（以節省磁盤空間），同時仍然可以在控制檯上打印全部日誌消息。
可是，在某些場景下，咱們但願不一樣的消息被不一樣的隊列消費。這時就要用到Direct類型的Exchange。
在Direct模型下，隊列與交換機的綁定，不能是任意綁定了，而是要指定一個RoutingKey（路由key）
消息的發送方在向Exchange發送消息時，也必須指定消息的routing key。

P：生產者，向Exchange發送消息，發送消息時，會指定一個routing key。
X：Exchange（交換機），接收生產者的消息，而後把消息遞交給 與routing key徹底匹配的隊列
C1：消費者，其所在隊列指定了須要routing key 爲 error 的消息
C2：消費者，其所在隊列指定了須要routing key 爲 info、error、warning 的消息
訂閱模型-Topic
Topic類型的Exchange與Direct相比，都是能夠根據RoutingKey把消息路由到不一樣的隊列。只不過Topic類型Exchange可讓隊列在綁定Routing key 的時候使用通配符！
Routingkey 通常都是有一個或多個單詞組成，多個單詞之間以」.」分割，例如： item.insert

通配符規則：
#：匹配一個或多個詞
*：匹配很少很多剛好1個詞

舉例：
audit.#：可以匹配audit.irs.corporate 或者 audit.irs`audit.*：只能匹配audit.irs`
在這個例子中，咱們將發送全部描述動物的消息。消息將使用由三個字（兩個點）組成的routing key發送。路由關鍵字中的第一個單詞將描述速度，第二個顏色和第三個種類：「<speed>.<color>.<species>」。
咱們建立了三個綁定：Q1綁定了綁定鍵「 .orange.」，Q2綁定了「..rabbit」和「lazy.＃」。
Q1匹配全部的橙色動物。
Q2匹配關於兔子以及懶惰動物的消息