阿粉之前也講述過關于 RabbitMQ 的相關內容，比如他們的配置，以及 RabbitMQ 整合 SpringBoot 使用，而且自己使用過之后，就會在自己的簡歷上面寫上自己使用 RabbitMQ 實現了什么功能，但是這就會導致，有些面試官就會問一些關于 RabbitMQ 的一些相關的問題，比如， RabbitMQ 中的交換機是什么， RabbitMQ 中的路由都有哪些？

反正諸如此類的問題，都是屬于相對簡單的問題，但是也不排除會有一些相對高級一點的問題，就比如接下來的關于 RabbitMQ 的協議的問題。

AMQP 協議

AMQP（高級消息隊列協議）是一個網絡協議。它支持符合要求的客戶端應用（application）和消息中間件代理（messaging middleware broker）之間進行通信。

消息代理（message brokers）從發布者（publishers）亦稱生產者（producers）那兒接收消息，并根據既定的路由規則把接收到的消息發送給處理消息的消費者（consumers）。

由于AMQP是一個網絡協議，所以這個過程中的發布者，消費者，消息代理 可以存在于不同的設備上。

這就是使用消息隊列最好的地方，消息的發布者，也就是生產者和消息費可以不在相同的設備上，但是可以保持通信。

AMQP協議是一個二進制協議，擁有一些現代特點：多信道、協商式、異步、安全、跨平臺、中立、高效。

AMQP通常被劃分為三層：

模型層定義了一套命令（按功能分類），客戶端應用可以利用這些命令來實現它的業務功能。

會話層負責將命令從客戶端應用傳遞給服務器，再將服務器的應答傳遞給客戶端應用，會話層為這個傳遞過程提供可靠性、同步機制和錯誤處理。

傳輸層提供幀處理、信道復用、錯誤檢測和數據表示。

實現者可以將傳輸層替換成任意傳輸協議，只要不改變AMQP協議中與客戶端應用程序相關的功能。實現者還可以使用其他高層協議中的會話層。

如果你要是去百度上所有 AMQP 反正各大博主上來就說 AMQP 0-9-1 ，但是也不說 這個 0-9-1 到底是什么意思，反正都是書中找的，直接介紹就完事。

這個東西，阿粉專門找了一些書籍，才了解這個東西指的是什么。

實際上 AMQP 后面所攜帶的 0-9-1 指的是他的版本號，主版本號和次版本號。我們約定版本由主版本號后面加小數點再加上次版本號組成（比如1-3表示主版本號為1，次版本號為3）。

主版本號保持不變，次版本號遞增。當AMQP工作組提升主版本號時，次版本號將被設置為0。因此，有可能出現這樣的版本序列：1-2，1-3，1-4，2-0，2-1……

旦本協議發布之后（主版本號大于1），應盡量防止次版本號遞增到9。不過在發布之前（版本0-x），由于會對本協議進行頻繁的修訂，可以不遵守這條約定。

而這也是大家在百度上所有 AMQP 協議中的 AMQP 0-9-1 的由來。

AMQP 模型

一個由關鍵實體和語義表示的邏輯框架，遵從AMQP規范的服務器必須提供這些實體和語義。為了實現本規范中定義的語義，客戶端可以發送命令來控制AMQP服務器。

實際上這個就是一個工作過程的簡介。

消息的生產者，將消息發送到交換機，然后交換機收到消息之后，根據不同的路由規則，發給綁定的隊列，最后 AMQP 代理會將消息投遞給訂閱了此隊列的消費者，或者消費者按照需求自行獲取。

也就是從 product ->exchange -> queue ->consumer

其實 AMQP 也是一個可編程的協議。

可編程協議是什么？

某種意義上說AMQP的實體和路由規則是由應用本身定義的，而不是由消息代理定義。包括像聲明隊列和交換機，定義他們之間的綁定，訂閱隊列等等關于協議本身的操作。

這雖然能讓開發人員自由發揮，但也需要他們注意潛在的定義沖突。當然這在實踐中很少會發生，如果發生，會以配置錯誤（misconfiguration）的形式表現出來。

應用程序（Applications）聲明AMQP實體，定義需要的路由方案，或者刪除不再需要的AMQP實體。

至于 RabbitMQ 中的 隊列，交換機，后還有路由啥的，阿粉就不說了，那個東西自己理解反而比別人說的有效。

唯一需要注意的是， 當一條消息發布的時候，發布者可能會指定一些消息屬性message attributes(也叫message meta-data消息元數據)，其中有一些消息屬性是用于消息中間件處理消息，其余的部分則是用于消息消費者對于消息中間件完全透明。

由于網絡的不穩定性，消息在傳輸過程中可能出現失敗的情況，鑒于此AMQP 0-9-1提供了一種消息確認機制message acknowledgements: 當一條消息傳遞給消費者后該消費者發送一條通知notifies給消息中間件來確認消息，無論是自動的還是開發者自己這樣做，當消息確認機制使用時，只有當消息代理收到通知后才會將該條或該組消息從消息隊列中移除。

在一些特定情況下，比如當消息不能被路由時，消息可能會被返回給消息發布者，或者刪除，或者如果消息代理實現了某種擴展插件，則這些無法被路由的消息可能會被放入一個稱之為dead letter queue(死亡標記隊列)的隊列中，發布者可以通過指定一些確定的消息屬性 message attributes來響應出現這種情景時消息應該如何被處理。