異步處理
應用解耦
流量削峰
系統架構
Broker:它提供一種傳輸服務,它的角色就是維護一條從生產者到消費者的路線，保證數據能按照指定的方式進行傳輸,
Exchange：消息交換機,它指定消息按什么規則,路由到哪個隊列。
Queue:消息的載體,每個消息都會被投到一個或多個隊列。
Binding:綁定，它的作用就是把exchange和queue按照路由規則綁定起來.
Routing Key:路由關鍵字,exchange根據這個關鍵字進行消息投遞。
vhost:虛擬主機,一個broker里可以有多個vhost，用作不同用戶的權限分離。
Producer:消息生產者,就是投遞消息的程序.
Consumer:消息消費者,就是接受消息的程序.
Channel:消息通道,在客戶端的每個連接里,可建立多個channel.
Fair dispath 公平分發
RabbitMQ就會使得每個Consumer在同一個時間點最多處理一個Message，換句話說,在接收到該Consumer的ack前,它不會將新的Message分發給它
分發到多個Consumer
Direct exchange
Exchange和兩個隊列綁定在一起,Q1的bindingkey是orange，Q2的binding key是black和green.
當Producer publish key是orange時,exchange會把它放到Q1上,如果是black或green就會到Q2上,其余的Message被丟棄.
Multiple bindings
多個queue綁定同一個key也是可以的,對於下圖的例子,Q1和Q2都綁定了black,對於routing key是black的Message，會被deliver到Q1和Q2，其余的Message都會被丟棄.
Topic exchange
Producer發送消息時需要設置routing_key，routing_key包含三個單詞和連個點號o,第一個key描述了celerity(靈巧),第二個是color(色彩),第三個是物種:
在這里我們創建了兩個綁定： Q1 的binding key 是”.orange.“； Q2 是 “..rabbit” 和 “lazy.#”：
- Q1感興趣所有orange顏色的動物
- Q2感興趣所有rabbits和所有的lazy的.
例子:rounting_key 為 “quick.orange.rabbit”將會發送到Q1和Q2中
rounting_key 為”lazy.orange.rabbit.hujj.ddd”會被投遞到Q2中,#匹配0個或多個單詞。
消息序列化
RabbitMQ使用ProtoBuf序列化消息,它可作為RabbitMQ的Message的數據格式進行傳輸,由於是結構化的數據,這樣就極大的方便了Consumer的數據高效處理,當然也可以使用XML，與XML相比,ProtoBuf有以下優勢:
1.簡單
2.size小了3-10倍
3.速度快了20-100倍
4.易於編程
6.減少了語義的歧義.
，ProtoBuf具有速度和空間的優勢，使得它現在應用非常廣泛
參考：http://blog.csdn.net/whoamiyang/article/details/54954780
https://www.cnblogs.com/jun-ma/p/4840869.html
rabbitMQ中consumer通過建立到queue的連接，創建channel對象，通過channel通道獲取message,
Consumer可以聲明式的以API輪詢poll的方式主動從queue的獲取消息，也可以通過訂閱的方式被動的從Queue中消費消息,
1、訂閱方式其實是向queue注冊consumer,通過rpc向queue server發送注冊consumer的消息，rabbitMQ Server在收到消息后，根據消息的內容類型判斷這是一個訂閱消息，這樣當MQ 中queue有消息時，會自動把消息通過該socket(長連接)通道發送出去。創建Connection后，會啟動MainLoop后台線程，循環從socket(FrameHandler)中獲取數據包(Frame) 每個Consumer都有一個BlockQueue，用於緩存從socket中獲取的消息。接下來，Consumer對象就可以調用api來從客戶端緩存的_queue中依次獲取消息，進行消費，參見QueueingConsumer.nextDelivery()
2、poll API方式
ChannelN：
GetResponse basicGet(String queue, boolean autoAck)
這種方式比較簡單，直接通過RPC從MQ Server端獲取隊列中的消息
Kafka、RabbitMQ、RocketMQ比較
Kafka：追求高吞吐量，不支持事務，對消息的重復、丟失、錯誤沒有嚴格要求，適合產生大量數據的互聯網服務的數據收集業務。
RabbitMQ：對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。
RocketMQ：具有高吞吐量、高可用性、適合大規模分布式系統應用的特點。