學習文檔：
http://rabbitmq.mr-ping.com/AMQP/AMQP_0-9-1_Model_Explained.html
注意：
1） 默認交換機（default exchange）實際上是一個由消息代理預先聲明好的沒有名字（名字為空字符串）的直連交換機（direct exchange）。它有一個特殊的屬性使得它對于簡單應用特別有用處：那就是每個新建隊列（queue）都會自動綁定到默認交換機上，綁定的路由鍵（routing key）名稱與隊列名稱相同。
eg. 當你聲明了一個名為"search-indexing-online"的隊列，AMQP代理會自動將其綁定到默認交換機上，綁定（binding）的路由鍵名稱也是為"search-indexing-online"。因此，當攜帶著名為"search-indexing-online"的路由鍵的消息被發送到默認交換機的時候，此消息會被默認交換機路由至名為"search-indexing-online"的隊列中。換句話說，默認交換機看起來貌似能夠直接將消息投遞給隊列，盡管技術上并沒有做相關的操作。
2） 交換機可以有兩個狀態：持久（durable）、暫存（transient）。持久化的交換機會在消息代理（broker）重啟后依舊存在，而暫存的交換機則不會（它們需要在代理再次上線后重新被聲明）。然而并不是所有的應用場景都需要持久化的交換機。
3）隊列在聲明（declare）后才能被使用。如果一個隊列尚不存在，聲明一個隊列會創建它。如果聲明的隊列已經存在，并且屬性完全相同，那么此次聲明不會對原有隊列產生任何影響。如果聲明中的屬性與已存在隊列的屬性有差異，那么一個錯誤代碼為406的通道級異常就會被拋出。
4）以"amq."開始的隊列名稱被預留做消息代理內部使用。如果試圖在隊列聲明時打破這一規則的話，一個通道級的403 (ACCESS_REFUSED)錯誤會被拋出。
5）如果AMQP的消息無法路由到隊列（例如，發送到的交換機沒有綁定隊列），消息會被就地銷毀或者返還給發布者。如何處理取決于發布者設置的消息屬性。
void basicPublish(String exchange, String routingKey, boolean mandatory, boolean immediate, BasicProperties props, byte[] body) throws IOException;
mandatory：true：如果exchange根據自身類型和消息routeKey無法找到一個符合條件的queue，那么會調用basic.return方法將消息返還給生產者。false：出現上述情形broker會直接將消息扔掉
6）消息如果只是存儲在隊列里是沒有任何用處的。被應用消費掉，消息的價值才能夠體現。在AMQP 0-9-1 模型中，有兩種途徑可以達到此目的：
- 將消息投遞給應用 ("push API")
- 應用根據需要主動獲取消息 ("pull API")
7）消費者應用（Consumer applications） - 用來接受和處理消息的應用 - 在處理消息的時候偶爾會失敗或者有時會直接崩潰掉。而且網絡原因也有可能引起各種問題。這就給我們出了個難題，AMQP代理在什么時候刪除消息才是正確的？AMQP 0-9-1 規范給我們兩種建議：
- 當消息代理（broker）將消息發送給應用后立即刪除。（使用AMQP方法：basic.deliver或basic.get-ok）
- 待應用（application）發送一個確認回執（acknowledgement）后再刪除消息。（使用AMQP方法：basic.ack）
前者被稱作自動確認模式（automatic acknowledgement model），后者被稱作顯式確認模式（explicit acknowledgement model）。在顯式模式下，由消費者應用來選擇什么時候發送確認回執（acknowledgement）。應用可以在收到消息后立即發送，或將未處理的消息存儲后發送，或等到消息被處理完畢后再發送確認回執（例如，成功獲取一個網頁內容并將其存儲之后）。
如果一個消費者在尚未發送確認回執的情況下掛掉了，那AMQP代理會將消息重新投遞給另一個消費者。如果當時沒有可用的消費者了，消息代理會死等下一個注冊到此隊列的消費者，然后再次嘗試投遞。
8）當一個消費者接收到某條消息后，處理過程有可能成功，有可能失敗。應用可以向消息代理表明，本條消息由于“拒絕消息（Rejecting Messages）”的原因處理失敗了（或者未能在此時完成）。當拒絕某條消息時，應用可以告訴消息代理如何處理這條消息——銷毀它或者重新放入隊列。當此隊列只有一個消費者時，請確認不要由于拒絕消息并且選擇了重新放入隊列的行為而引起消息在同一個消費者身上無限循環的情況發生。
9） 在AMQP中，basic.reject方法用來執行拒絕消息的操作。但basic.reject有個限制：你不能使用它決絕多個帶有確認回執（acknowledgements）的消息。但是如果你使用的是RabbitMQ，那么你可以使用被稱作negative acknowledgements（也叫nacks）
void basicNack(long deliveryTag, boolean multiple, boolean requeue) throws IOException;
multiple：是否批量.true:將一次性拒絕所有小于deliveryTag的消息。
10）在多個消費者共享一個隊列的案例中，明確指定在收到下一個確認回執前每個消費者一次可以接受多少條消息是非常有用的。RabbitMQ只支持通道級的預取計數，而不是連接級的或者基于大小的預取。
11）AMQP連接通常是長連接。AMQP是一個使用TCP提供可靠投遞的應用層協議。AMQP使用認證機制并且提供TLS（SSL）保護。當一個應用不再需要連接到AMQP代理的時候，需要優雅的釋放掉AMQP連接，而不是直接將TCP連接關閉。
12）有些應用需要與AMQP代理建立多個連接。無論怎樣，同時開啟多個TCP連接都是不合適的，因為這樣做會消耗掉過多的系統資源并且使得防火墻的配置更加困難。AMQP 0-9-1提供了通道（channels）來處理多連接，可以把通道理解成共享一個TCP連接的多個輕量化連接。
在涉及多線程/進程的應用中，為每個線程/進程開啟一個通道（channel）是很常見的，并且這些通道不能被線程/進程共享。
一個特定通道上的通訊與其他通道上的通訊是完全隔離的，因此每個AMQP方法都需要攜帶一個通道號，這樣客戶端就可以指定此方法是為哪個通道準備的。
