1.為什么使用信道（channel）而不使用TCP連接發(fā)送AMQP命令？##
對操作系統(tǒng)來說頻繁的建立和銷毀TCP連接開銷非常昂貴，而操作系統(tǒng)每秒建立的連接是有上限的，性能瓶頸不可避免，而只建立一條TCP連接無疑是一個很好的方案，在這條連接當(dāng)中建立多條信道與RabbitMQ進行私密通信，相當(dāng)于光纖電纜一樣，一條電纜有多條光束，信道是沒有限制的
2.隊列##
1、AMQP的命令
basic.consume與basic.get 如果需要消息一到達隊列就自動接收的話，應(yīng)該使用basic.consume basic.get會訂閱消息，獲得單條消息，然后取消訂閱，值得注意的是不應(yīng)該循環(huán)basic.get來替代basic.consume，應(yīng)該理性使用basic.consume實現(xiàn)高吞吐量
消息如果到達無人訂閱的隊列，消息會在隊列中等待，知道有消費者訂閱到該隊列
2、接收消息
消費者確認(rèn)消息告訴RabbitMQ已正確接收RabbitMQ會安全的把消息從隊列上刪除， 如果消費者收到一條消息，確認(rèn)之前RabbitMQ斷開了連接（或者從隊列上取消訂閱），RabbitMQ會認(rèn)為這條消息沒有被分發(fā)，然后分發(fā)給下一個訂閱者。如果應(yīng)用程序處理消息耗時，則可以延遲確認(rèn)消息，防止源源不斷的消息涌入
** 3、拒絕接收 消息未確認(rèn)之前 **
a.消費者從RabbitMQ服務(wù)器斷開連接，它會將消息入隊并發(fā)送給下一個消費者，但是這種連接/斷開方式會增加服務(wù)器負(fù)擔(dān)
b.可以使用basic.reject命令拒絕接收消息，參數(shù)為true，會發(fā)送給下一個消費者，false時，會把消息從隊列中移除不會分發(fā)給下一個消費者
** 4、隊列設(shè)置 **
如果想擁有私人隊列只為一個消費者服務(wù)，可以設(shè)置exclusive參數(shù)為true 如果需要臨時隊列和結(jié)合exclusive和auto_delete，auto_delete在消費者取消訂閱時，會自動刪除，都設(shè)置為true
** 3.三種基本交換類型 **
- direct交換器非常簡單：如果路由鍵匹配的話，消息就會被投遞到相應(yīng)的隊列當(dāng)中；
- fanout交換器會將收到的消息廣播到綁定的隊列上；
- topic交換器使得來自不同源頭的消息能夠到達同一個隊列。
** 4.虛擬主機（vhost）的作用**
- 邏輯分離允許為不同應(yīng)用程序安全保密的運行數(shù)據(jù)，將rabbit的眾多客戶區(qū)分開來，避免隊列和交換器的命名沖突；
- 權(quán)限控制以vhost為單位；
- vhost之間是絕對隔離的，無法將vhost1上的交換器綁定到vhost2中的隊列去；
- 可以安全的遷移到新的RabbitMQ服務(wù)器上處理新的負(fù)載，不會有任何命名沖突
- vhost不僅消除了在基礎(chǔ)架構(gòu)中為每一層都運行一個RabbitMQ服務(wù)器，也避免了為每一層創(chuàng)建不同集群
** 5.持久化的策略**
durable屬性決定了RabbitMQ是否需要在崩潰或者重啟之后重新創(chuàng)建隊列（或者交換器） 持久化消息三個要點： 把他的投遞模式（delivery mode）選項設(shè)置為2（持久）； 發(fā)送到持久化的交換器上； 到達持久化的隊列。 特點： 持久性消息從服務(wù)器重啟中恢復(fù)的方式是寫入磁盤的持久化日志文件，當(dāng)發(fā)布一條持久性消息到持久化的交換器上時，消息提交到日志文件后才會響應(yīng)；
持久性消息如果路由到了非持久化的隊列當(dāng)中，會自動從持久性日志中移除，無法從服務(wù)器重啟中恢復(fù)；一旦被正確消費（經(jīng)過確認(rèn)后），RabbitMQ會在持久化日志中將這條消息標(biāo)記為等待垃圾收集。在消費之前，如果重啟，服務(wù)器會重建交換器和隊列以及綁定，重播持久性日志文件中的消息到合適的隊列或者交換器上，這取決與宕機時消息處在哪個環(huán)節(jié)上
** 6.解決事務(wù)的方案：發(fā)送方確認(rèn)模式**
由于AMQP內(nèi)部事務(wù)對性能有很大瓶頸，現(xiàn)采取發(fā)送方確認(rèn)模式保證事務(wù)，將信道設(shè)置為confirm模式，所有在此信道上發(fā)布的消息都會有一個唯一的ID號，當(dāng)被投遞到匹配的隊列時，信道就會發(fā)送一個發(fā)送方確認(rèn)模式給生產(chǎn)者應(yīng)用程序，這個模式是異步的，應(yīng)用程序可以等待確認(rèn)的同時繼續(xù)發(fā)送下一條，但如果是持久化的消息，會在寫入磁盤之后消息發(fā)出。
如果發(fā)送內(nèi)部錯誤而導(dǎo)致消息丟失，RabbitMQ會發(fā)送一條nack(not acknowledged,未確認(rèn))消息，這種模式下每分鐘可追蹤數(shù)以百萬計的消息投遞
** 7、性能特點 **
- 可靠性(Reliability) RabbitMQ提供很多特性供我們可以在性能和可靠性作出折中的選擇，包括持久化、發(fā)送確認(rèn)、發(fā)布者確認(rèn)和高可用性等。
- 彈性選路(Flexible Routing) 消息在到達隊列前通過交換（exchanges）來被選路。RabbitMQ為典型的選路邏輯設(shè)計了幾個內(nèi)置的交換類型。對于更加復(fù)雜的選路，我們可以將exchanges綁定在一起或者寫屬于自己的exchange類型插件。
- 集群化(Clustering) 在一個局域網(wǎng)內(nèi)的幾個RabbitMQ服務(wù)器可以集群起來，組成一個邏輯的代理人。
- 聯(lián)盟(Federation) 對于那些需要比集群更加松散和非可靠連接的服務(wù)器來說，RabbitMQ提供一個聯(lián)盟模型（Federation Model）
- 高可用隊列(High Available Queue) 可以在一個集群里的幾個機器里對隊列做鏡像，確保即時發(fā)生了硬件失效，你的消息也是安全的。
- 多種協(xié)議（Multi-protocol） RabbitMQ支持消息在多種協(xié)議中傳輸。
- 多客戶端（Many Clients） RabbitMQ客戶端有你幾乎能想象到的任何語言。
- 管理界面（Management UI） RabbitMQ附帶一個容易使用的管理界面,允許您監(jiān)控和控制你的消息broker服務(wù)器的方方面面。
- 跟蹤(Tracing) 如果你的消息系統(tǒng)行為異常，RabbitMQ提供跟蹤支持來找出錯誤的根源。
- 插件系統(tǒng)(Plugin System) RabbitMQ提供各種方式的插件擴展，我們可以實現(xiàn)自己的插件。
使用任務(wù)隊列一個優(yōu)點是能夠輕易地并行處理任務(wù)。當(dāng)處理大量積壓的任務(wù)，只要增加工作隊列，通過這個方式，能夠?qū)崿F(xiàn)輕易的縮放。
