最近用到了一些RabbitMQ的東西，看了官方的Get Started，以此為模板總結一下。
（1）生產者（發送方）發送消息到ExChange（含參：routingkey），ExChange通過bindingkey確定消息傳入哪一個Queue，消費者（接收方）通過監聽Queue來獲取消息。
其中需要注意的是：生產者（Producer）永遠不會向隊列（Queue）直接發送消息。
（2）ExChange通過BindKey來和Queue進行關聯保定的，Binding表示一種Exchange服務器和Queue之間的關系，或者說Queue對Exchange服務器中的內容感興趣。
（3）通過上面可以知道，生產者是將消息發送給ExChange服務器的，但是ExChange服務器是怎么知道如何處理這些Message呢，是通過ExChange Type，ExChange Type主要有四類：
- direct：消息會流向bindingkey和routingkey相同的隊列；
- topic：topic消息的routingkey必需有多個單詞，單詞間以“.”間隔，比如：stock.usd.nyse。發送消息伴隨一個特定的routingkey，他會發送給所有滿足bindingkey的隊列
- fanouts：廣播消息給所有知道的隊列
- headers：通過頭部信息進行匹配（這種方式在Get Started中沒有詳細提及）
（4）其常見的消息分發模型如下：
1.簡易的一對一的生產者消費者模型
2.一對多的工廠模型，其主要需要注意的點是默認為公平分配，即C1、C2兩個消費者拿到的東西是一樣多的，其需要設置prefetch_count來改變這種情況。
3.訂閱/發布模式，其采用一種廣播模式進行對已知的隊列進行消息發送。
3.direct這種確定值的路由狀態，即routingkey為orange的消息，只會發送到與Exchange的Bindingkey為orange的隊列中，而，在fanout廣播下會忽略這些值（orange，black等）。
即：其如果routingkey都一致，都是black，那么Exchange收到的所有routingkey為black的消息都會發送給Q1、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 | Q1、Q2 |
| lazy.orange.fox | Q1、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，與自己發出的進行匹配，成功則標示消息已經被消費。