RabbitMQ是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量級，更適合于企業級的開發。同時實現了Broker構架，這意味著消息在發送給客戶端時先在中心隊列排隊。對路由，負載均衡或者數據持久化都有很好的支持。

 　　它支持開放的高級消息隊列協議 (AMQP，Advanced Message Queuing Protocol)，從根本上避免了生產廠商的封閉，使用任何語言的各種客戶都可以從中受益。這種協議提供了相當復雜的消息傳輸模式，所以基本上不需要MassTransit或NServiceBus的配合。它還具有“企業級”的適應性和穩定性。這些東西對我的客戶來說十分的有吸引力。

　　RabbitMQ從信息接收者角度可以看做三種模式,一對一,一對多(此一對多并不是發布訂閱，而是每條信息只有一個接收者)和發布訂閱。其中一對一是簡單隊列模式，一對多是Worker模式，而發布訂閱包括發布訂閱模式，路由模式和通配符模式，為什么說發布訂閱模式包含三種模式呢，其實發布訂閱，路由，通配符三種模式都是使用只是交換機(Exchange)類型不一致

 docker安裝RabbitMQ請參考：http://www.rzrgm.cn/gygtech/p/14860921.html

 　　想要學習后面的幾種消息具體的發送模式，這個模型圖就必須理解清楚，因為這幾種方式就是對這個模型不同程度的選擇和縮減

• Producer：消息的生產者（發送消息的程序）。
• Connection：應用程序與Broker之間的網絡連接。
• Channel：信道，即信息傳輸的通道，可以建立多個 Channel，每個 Channel 代表一個會話任務。
• 信道是建立在 TCP 連接內的虛擬連接，信息的讀寫都通過信道傳輸，因為對于操縱系統而言，建立和銷毀 TCP 是非常昂貴的，所以引入了信道的概念，以復用一條 TCP 連接。

• Broker(Server) ：標識消息隊列服務器實體，例如這里就是 RabbitMQ Server。
• Virtual Host：虛擬主機，一個 Broker 中可以設置多個 Virtual Host，用作不同用戶的權限隔離。
• Broker 可以理解為整個數據庫服務，而 Virtual Host 就是其中每個數據庫的感覺，不同項目可以對應不同的數據庫，其中有著項目所屬的業務表等等。
• 每個 Virtual Host 中，可以有若干個 Exchange 和 Queue。

• Exchange：交換機，用來接收生產者發送的消息，然后將這些消息根據路由鍵發送到隊列。
• Binding：Exchange 和 Queue 之間的虛擬連接，Binding 中可以包括多個 Routing key。
• Routing key：路由規則，虛擬機用它來確認如何路由一個特定消息。
• Queue：消息隊列，它是消息的容器，用來保存消息，每一條消息都能傳入一個或者多個隊列中，等待消費者消費，即取出這個消息。
• Consumer：消息的消費者（接收消息的程序）。

 RabbitMQ一共有五種常用的隊列：

• 第一種：簡單隊列（一對一模式）耦合性高，生產消費一一對應。
• 第二種：WorkQueues（工作隊列），一個生產，多個消費者共同處理消息。
• 第三種：訂閱模式，1一個生產者多個消費者，每一個消費者有自己的一個隊列，生產者直接將消息發送給交換機，交換機將消息發送給隊列，每一個隊列都需要綁定到交換機。這種模式可以滿足消費者發布一個消息，多個消費者消費同一信息的需求，但C1、C2消費的都是相同的數據，有時我們需要C1和C2消費的信息只有部分差異，比如我們需求：C1消費增加的數據，C2消費編輯、增加和刪除的數據。
• 第四種：路由模式，路由模式是在訂閱模式基礎上的完善，可以在生產消息的時候，加入Key值，與key值匹配的消費者消費信息。但路由模式中，就如三中提到的C1、C2、如果C2對應的類型更多，就需要寫很多key值。但其實它只與C1有一點差別

• 第五種：通配符模式是在路由模式的升級，他允許key模糊匹配。*代表一個詞，#代表一個或多個詞。通過通配符模式我們就可以將C1對應的一個key準確定為item.add。而C2我們就不需要一一寫出key值，而是用item.#代替即可。