生產者(producer)建立訊息，然後釋出到代理伺服器(RabbitMQ)。訊息包含兩部分內容：有效載荷(payload)和標籤(label)。有效載荷就是你想要傳輸的資料，它可以是任何內容，標籤描述了有效載荷，並且RabbitMQ用它來決定誰將獲得訊息的拷貝。

　　在應用程式和Rabbit代理伺服器之間建立一條TCP連線，一旦TCP連線開啟，應用程式就可以建立一條AMQP通道。通道是建立在“真實的”TCP連線內的虛擬連線。AMQP命令都是通過通道傳送出去的。每條通道都會被指派一個唯一的ID。不論是傳送訊息，訂閱佇列貨接收訊息，這些動作都是通過通道完成的。

　　AMQP訊息路由有三部分組成：交換器，佇列和繫結。生產者把訊息釋出到交換器上；訊息最終到達佇列，並被消費者接收；繫結決定了訊息如何從路由器到特定的佇列。消費者通過以下兩種方式從特定的佇列中接收訊息：

　　　　通過AMQP的baisc.consume命令訂閱。這樣會將通道置為接收模式，直到取消對佇列的訂閱為止。

　　　　向佇列請求單條訊息是通過AMQP的basic.get命令實現的。這樣可以讓消費者接收佇列中的下一條訊息。basic.get會訂閱訊息，獲得單條訊息，然後取消訂閱。消費者應該使用basic.consume來實現高吞吐量。

　　當Rabbit佇列擁有多個消費者時，佇列收到的訊息將以迴圈(round-robin)的方式傳送給消費者。每條訊息只會傳送一個訂閱的消費者。訊息者通過AMQP的basic.ack命令顯式地向RabbitMQ傳送一個確認，或在訂閱到佇列的時候將auto_ack引數設定為true。當設值了auto_ack時，一旦訊息者接收訊息時，RabbitMQ會自動視為其確認了訊息。

　　若處理訊息的時候遇到了不可恢復的錯誤，但由於硬體問題，隻影響到當前的消費者。只要訊息尚未確認，則有兩個選擇：

　　　　把消費者從RabbitMQ伺服器斷開連線，此時RabbitMQ自動重新把訊息入隊併發送給另一消費者。缺點時連線/斷開的方式會增加RabbitMQ的負擔

　　　　使用AMQP的basic.reject命令。若把reject命令的requeue引數設定為true，RabbitMQ會將訊息重新發送給下一個訂閱的消費者。

　　消費者和生產者都可以使用AMQP的queue.declare命令來建立佇列。若消費者在同一條通道上訂閱了另一個佇列的話，則無法在宣告隊列了，必須先取消訂閱，將通道置為“傳輸”模式。當建立佇列時，需要制定佇列名稱。消費者訂閱佇列時需要佇列名稱，並在繫結時也需要指定佇列名稱。若不指定佇列名稱，Rabbit會分配一個隨機名稱並在queue.declare命令的響應中返回。在建立佇列時設定exclusive為true時，佇列將變為私有的。當最後一個消費者取消訂閱時，使用auto-delete引數可以讓佇列自動移除。當想檢測佇列是否存在時，可以設定queue.declare的passive選項為true。在該設定下，若該佇列存在，queue.declare命令會返回成功，否則命令不會建立一個佇列而返回一個錯誤。

　　佇列是AMQP訊息通訊的基礎模組：為訊息提供了住處，訊息在此等待消費；對負載均衡來說，只需附加消費者，並讓RabbitMQ以迴圈的方式均勻地分配發來的訊息；佇列是Rabbit中訊息的最後的終點。

　　當你想要將訊息投遞到佇列時，通過把訊息傳送給交換器來完成。然後根據確定的規則，RabbitMQ將會決定訊息該投遞到哪個佇列。這些規則被稱為路由鍵(routing key)。佇列通過路由鍵繫結到交換器。當你把訊息傳送到代理伺服器時，訊息將擁有一個路由鍵，即使路由鍵時空的，RabbitMQ也會將其和繫結使用的路由鍵進行匹配。若匹配，則該訊息將投遞到佇列，若不匹配，訊息將進入“黑洞”。

　　協議中定義了四種不同型別交換器：direct，fanout，topic和headers。

　　headers交換器：允許你匹配AMQP訊息的header而非路由鍵。

　　direct交換器：如果路由鍵匹配，訊息就被投遞到對應的佇列。伺服器必須實現direct型別交換器，包含一個空白字串名稱的預設交換器，當宣告一個佇列時，它會自動繫結到預設交換器，並以佇列名稱作為路由鍵。

　　　　channel−>basicpublish($channel->basi{c}_{p}ublish($msg, ”, ‘queue-name’)；//第一個引數是傳送資訊；第二個引數exchange，此處是空的字串，指定了預設交換器；第三個參事是路由鍵。

　　fanout交換器：將收到的訊息廣播到繫結的佇列上。當傳送一條訊息到fanout交換器時，它會把訊息投遞到所有附加在此交換器上的佇列。

　　topic交換器：使來自不同源頭的訊息能夠到達同一個佇列。

　　　　channel−>basicpublish($channel->basi{c}_{p}ublish($msg, ‘logs-exchange’, ‘error.msg-index’);

　　　　$channel->basic_bind(‘msg-inbox-errors’, ‘logs-exchange’, ‘error.msg-index’);

　　　　$channel->basic_bind(‘msg-index-logs’, ‘logs-exchange’, ‘*.msg-inbox’);

　　每一個RabbitMQ伺服器都能建立虛擬訊息伺服器，我們稱之為虛擬主機(vhost)。每一個vhost本質上是一個mini版的RabbitMQ伺服器，擁有自己的佇列，交換器和繫結。它有自己的許可權機制，這使得你能夠安全地使用一個RabbitMQ伺服器來服務眾多應用程式。vhost通過在各個例項間提供邏輯上的分離，允許為不同應用程式安全保密地執行資料。當在RabbitMQ建立一個使用者時，使用者通常會被指派給至少一個vhost，並且只能訪問vhost內的佇列，交換器和繫結。當在RabbitMQ叢集上建立vhost時，整個叢集上都會建立該vhost。vhost不僅消除了為基礎架構中的每一層執行一個RabbitMQ伺服器的需要，同樣也避免了為每一層建立不同叢集。通過使用rabbitmqctl add_vhost vhost_name來建立一個vhost。通過rabbitmqctl delete_vhost vhost-name來刪除vhost。通過rabbitmqctl list_vhosts來顯式所有的vhost。

　　佇列和交換器的durable屬性預設為false。當RabbitMQ崩潰或重啟後所有資料將會丟失。因此應該將佇列和交換器設定為true。能從AMQP伺服器崩潰中恢復的訊息稱之為持久化訊息。在訊息釋出前，通過把它的“投遞模式(delivery mode)”設定為2來把訊息標記成持久化。因此，若訊息要從Rabbit崩潰中恢復，需要把它的投遞模式選項設定為2；傳送到持久化的交換器；到達持久化的佇列。RabbitMQ確保永續性訊息能從伺服器重啟中恢復的方式是，將它們寫入磁碟上的一個持久化日誌檔案。當釋出一條永續性資訊導持久交換器上時，Rabbit會在訊息提交到日誌檔案後才傳送響應。使用持久化機制會導致效能的下降，因為要不斷將訊息寫入磁碟同時會極大減少RabbitMQ伺服器每秒可處理的訊息總數。永續性訊息在RabbitMQ內建叢集環境下工作得並不好，若叢集中某個節點崩潰了，則這個佇列也就從整個叢集中消失了。若節點宕機，則其他佇列也無法使用了。若要求單臺Rabbit伺服器每秒處理10w訊息，生產者可以在單獨的通道上監聽應答佇列。若訊息應答未在合理時間範圍內到達，生產者可以重新發送訊息。即要保證訊息的投遞決定了相對於其他型別的訊息會有更低的吞吐量。

　　在AMQP中，在把通道設定成事務模式後，通過通道傳送那些想要確認的訊息之後還有很多其他AMQP命令，這些命令的執行與否取決於第一條訊息傳送是否成功。一旦傳送完所有命令，就可以提交事務了。若事務中的首次釋出成功了，那麼通道會在事務中完成其他AMQP命令，若失敗，則其他AMQP命令將不會執行。使用事務會造成嚴重的效能下降，降低2～10倍的訊息吞吐量並且使生產者應用程式產生同步。因此，RabbitMQ提出了傳送方確認模式，即將通道設定為confirm模式。一旦通道進入confirm模式，所有在通道上釋出的訊息會被指派唯一一個ID號(由於一條通道只能被耽單個程使用，因而可以確保通道上釋出的訊息是連續的。因此RabbitMQ做了個簡單的假設：任一通道上釋出的訊息將獲得ID1，並且通道接下來的每一條訊息的ID都將步進1。每次應用程式通道釋出訊息時，需要把計數器加1)。一旦訊息被投遞給所有匹配的佇列後，通道會發送一個傳送方確認模式給生產者應用程式使得生產者知曉訊息已經到達隊列了。傳送方確認的好處是移步，生產者可以在等待確認的同時繼續傳送下一條。當確認訊息最終受到時，生產者應用的回撥方法會被觸發來處理確認資訊。若Rabbit發生了內部錯誤而導致資訊丟失，Rabbit會發送nack訊息。由於沒有回滾，傳送方確認模式更加輕量級，同時對Rabbit代理伺服器的效能影響幾乎可以忽略不計。