歷史
今天聊聊消息隊列
Advanced Message Queuing Protocol （AMQP）
AMQP：前進消息隊列協議
歷史：
消息隊列來源已久煮寡，80年代最早在金融交易中囊扳，高盛等公司采用Teknekron公司的產品，當時的Message queuing軟件叫做：the information bus（TIB）。
TIB被電信和通訊公司采用炭菌，路透社收購了Teknekron公司。之后杠娱，IBM開發(fā)了MQSeries乏奥，微軟開發(fā)了Microsoft Message Queue（MSMQ）。
這些商業(yè)MQ供應商的問題是廠商鎖定登渣，價格高昂噪服。2001年，Java Message queuing試圖解決鎖定和交互性的問題胜茧，但對應用來說反而更加麻煩了粘优。
于是2004年，摩根大通和iMatrix開始著手Advanced Message Queuing Protocol （AMQP）開放標準的開發(fā)呻顽。
2006年雹顺，AMQP規(guī)范發(fā)布。2007年廊遍，Rabbit技術公司基于AMQP標準開發(fā)的RabbitMQ 1.0 發(fā)布无拗。后來又被spring收購
AMPQ是使用Erlang開發(fā)的，Erlang這哥們主要用來搞游戲與電信方面的東西昧碉，ok英染，下面說說AMPQ又什么用?
應用
亦
RabbitMQ Server：維持roducer到Consumer的路線揽惹，保證數據能夠按照指定的方式進行傳輸。但是這個保證也不是100%的保證
Client A & B：數據的發(fā)送方四康，一個Message有兩個部分：payload（有效載荷）和label（標簽）搪搏，payload顧名思義就是傳輸的數據。label是exchange的名字或者說是一個tag闪金，
它描述了payload疯溺，而且RabbitMQ也是通過這個label來決定把這個Message發(fā)給哪個Consumer。AMQP僅僅描述了label哎垦，而RabbitMQ決定了如何使用這個label的規(guī)則囱嫩。
Client 1，2漏设，3：數據的接收方
Exchanges are where producers publish their messages.
Queuesare where the messages end up and are received by consumers
Bindings are how the messages get routed from the exchange to particular queues.
還有幾個概念是上述圖中沒有標明的墨闲，那就是Connection（連接），Channel（通道郑口，頻道）鸳碧。
Connection： 就是一個TCP的連接。Producer和Consumer都是通過TCP連接到RabbitMQ Server的犬性。以后我們可以看到瞻离，程序的起始處就是建立這個TCP連接。
Channels： 虛擬連接乒裆。它建立在上述的TCP連接中套利。數據流動都是在Channel中進行的。也就是說鹤耍，一般情況是程序起始建立TCP連接日裙，第二步就是建立這個Channel。
建立和關閉TCP連接是有代價的惰蜜，頻繁的建立關閉TCP連接對于系統的性能有很大的影響，而且TCP的連接數也有限制受神，這也限制了系統處理高并發(fā)的能力
一些說明
默認情況下抛猖，如果Message 已經被某個Consumer正確的接收到了，那么該Message就會被從queue中移除鼻听。當然也可以讓同一個Message發(fā)送到很多的Consumer财著。
如果一個queue沒被任何的Consumer Subscribe（訂閱），那么撑碴，如果這個queue有數據到達撑教，那么這個數據會被cache，不會被丟棄醉拓。當有Consumer時伟姐，這個數據會被立即發(fā)送到這個Consumer收苏，這個數據被Consumer正確收到時，這個數據就被從queue中刪除愤兵。
那么什么是正確收到呢鹿霸？通過ack。每個Message都要被acknowledged（確認秆乳，ack）懦鼠。我們可以顯示的在程序中去ack，也可以自動的ack屹堰。如果有數據沒有被ack肛冶，那么：
RabbitMQ Server會把這個信息發(fā)送到下一個Consumer。
如果這個app有bug扯键，忘記了ack睦袖，那么RabbitMQ Server不會再發(fā)送數據給它，因為Server認為這個Consumer處理能力有限忧陪。
而且ack的機制可以起到限流的作用（Benefitto throttling）：在Consumer處理完成數據后發(fā)送ack扣泊，甚至在額外的延時后發(fā)送ack，將有效的balance Consumer的load嘶摊。
當然對于實際的例子延蟹，比如我們可能會對某些數據進行merge，比如merge 4s內的數據叶堆，然后sleep 4s后再獲取數據阱飘。特別是在監(jiān)聽系統的state，我們不希望所有的state實時的傳遞上去虱颗，而是希望有一定的延時沥匈。這樣可以減少某些IO，而且終端用戶也不會感覺到忘渔。
4.2 Reject a message
有兩種方式高帖，第一種的Reject可以讓RabbitMQ Server將該Message 發(fā)送到下一個Consumer。第二種是從queue中立即刪除該Message畦粮。
4.3 Creating a queue
Consumer和Procuder都可以通過 queue.declare 創(chuàng)建queue散址。對于某個Channel來說，Consumer不能declare一個queue宣赔，卻訂閱其他的queue预麸。當然也可以創(chuàng)建私有的queue。
這樣只有app本身才可以使用這個queue儒将。queue也可以自動刪除吏祸，被標為auto-delete的queue在最后一個Consumer unsubscribe后就會被自動刪除。那么如果是創(chuàng)建一個已經存在的queue呢钩蚊？
那么不會有任何的影響贡翘。需要注意的是沒有任何的影響蹈矮，也就是說第二次創(chuàng)建如果參數和第一次不一樣，那么該操作雖然成功床估，但是queue的屬性并不會被修改含滴。
那么誰應該負責創(chuàng)建這個queue呢？是Consumer丐巫，還是Producer谈况？
如果queue不存在，當然Consumer不會得到任何的Message递胧。但是如果queue不存在碑韵，那么Producer Publish的Message會被丟棄。所以缎脾，還是為了數據不丟失祝闻，Consumer和Producer都try to create the queue！反正不管怎么樣遗菠，這個接口都不會出問題联喘。
queue對load balance的處理是完美的。對于多個Consumer來說辙纬，RabbitMQ 使用循環(huán)的方式（round-robin）的方式均衡的發(fā)送給不同的Consumer豁遭。
4.4 Exchanges
從架構圖可以看出，Procuder Publish的Message進入了Exchange贺拣。接著通過“routing keys”蓖谢， RabbitMQ會找到應該把這個Message放到哪個queue里。queue也是通過這個routing keys來做的綁定譬涡。
有三種類型的Exchanges：direct, fanout,topic闪幽。 每個實現了不同的路由算法（routing algorithm）。
· Direct exchange: 如果 routing key 匹配, 那么Message就會被傳遞到相應的queue中涡匀。其實在queue創(chuàng)建時盯腌，它會自動的以queue的名字作為routing key來綁定那個exchange。
· Fanout exchange: 會向響應的queue廣播陨瘩。
· Topic exchange: 對key進行模式匹配腕够，比如ab*可以傳遞到所有ab*的queue。
4.5 Virtual hosts
每個virtual host本質上都是一個RabbitMQ Server拾酝，擁有它自己的queue，exchagne卡者，和bings rule等等蒿囤。這保證了你可以在多個不同的application中使用RabbitMQ。
