最近用到了一些RabbitMQ的東西，看了官方的Get Started，以此爲模板總結一下。json
（1）生產者（發送方）發送消息到ExChange（含參：routingkey），ExChange經過bindingkey肯定消息傳入哪個Queue，消費者（接收方）經過監聽Queue來獲取消息。服務器
其中須要注意的是：生產者（Producer）永遠不會向隊列（Queue）直接發送消息。app
（2）ExChange經過BindKey來和Queue進行關聯保定的，Binding表示一種Exchange服務器和Queue之間的關係，或者說Queue對Exchange服務器中的內容感興趣。函數
（3）經過上面能夠知道，生產者是將消息發送給ExChange服務器的，可是ExChange服務器是怎麼知道如何處理這些Message呢，是經過ExChange Type，ExChange Type主要有四類：fetch
- direct：消息會流向bindingkey和routingkey相同的隊列；
- topic：topic消息的routingkey必需有多個單詞，單詞間以「.」間隔，好比：stock.usd.nyse。發送消息伴隨一個特定的routingkey，他會發送給全部知足bindingkey的隊列
- fanouts：廣播消息給全部知道的隊列
- headers：經過頭部信息進行匹配（這種方式在Get Started中沒有詳細說起）
（4）其常見的消息分發模型以下：ui
1.簡易的一對一的生產者消費者模型spa
2.一對多的工廠模型，其主要須要注意的點是默認爲公平分配，即C一、C2兩個消費者拿到的東西是同樣多的，其須要設置prefetch_count來改變這種狀況。 3d
3.訂閱/發佈模式，其採用一種廣播模式進行對已知的隊列進行消息發送。blog
3.direct這種肯定值的路由狀態，即routingkey爲orange的消息，只會發送到與Exchange的Bindingkey爲orange的隊列中，而，在fanout廣播下會忽略這些值（orange，black等）。隊列
即：其若是routingkey都一致，都是black，那麼Exchange收到的全部routingkey爲black的消息都會發送給Q一、Q2兩個隊列。這樣就已經不具有Direct肯定路由的特性了，這種狀況就和fanout廣播的原理同樣了，以下：
4.還有這種通配符模型（TOPIC），以及其相似的指定模型（DIRECT），topic模型是最具備變換性質的模型，其經過「*」和「#」兩種配置符號進行EXCHANGE和QUEUE的綁定，可以經過特定的routingkey綁定方式實現DIRECT和FANOUTS類型。
（1）topic模式下的routingkey，必須由一系列的單詞組成，單詞之間以「.」間隔，好比：stock.usd.nyse；
（2）topic有兩種通配符： * 標示一個單詞，# 標示零個或多個單詞 （Y.X.Z，單詞是以.來肯定的，Y、X、Z即爲三個單詞）
好比這種狀況下：
| 消息的RoutingKey | 會接收消息的通道編號 |
| quick.orange.rabbit | Q一、Q2 |
| lazy.orange.fox | Q一、Q2 |
| lazy.orange.male.rabbit | Q2 |
須要注意的是，若是routingkey匹配了該通道的多條bindingkey，消息也不會屢次發送，另外：
- 若是全部通道的bindingkey都是#，那麼這種模式下的topic就和fanout同樣了；
- 若是全部通道的bindingkey都不包含*和#，那麼這種模式下的topic和direct同樣了。
5.還有一種RPC，遠程服務型，其可以實現消息回調，即客戶端經過RabbitMQ訪問服務端，服務端接收到消息後，再返回信息給客戶端，其由函數ConvertSendandReceive（）實現，具體過程以下：
能夠看到其發送的消息有一些參數：
- deliveryMode：if=2 - persistenet else - transient
- contentType：數據類型，好比：application/json
- replyto：用於標示回調通道名稱
- correlation_id：標識請求和回覆
如上圖：其客戶端發送了reply_to=amqp.gen-x a2... 那麼服務端回覆的通道就是amqp.gen-xa2....
客戶端接收到了服務端發回來的coorelation_id，與本身發出的進行匹配，成功則標示消息已經被消費。