RabbitMQ的AMQP协议是什么？我用RabbitMQ实现了什么功能，但是这会引起一些面试官问一些RabbitMQ的相关问题，比如RabbitMQ中的开关是什么，RabbitMQ中的路由是什么？反正像这样的题都是比较简单的题，但是不排除会有一些比较高级的题，比如下一个关于RabbitMQ协议的题。AMQP协议AMQP（高级消息队列协议）是一种网络协议。它支持合格的客户端应用程序（application）和消息中间件代理（messagingmiddlewarebroker）之间的通信。消息代理（messagebroker）从发布者（也称为生产者）接收消息，并将接收到的消息发送给消费者（consumer），消费者根据既定的路由规则处理消息。由于AMQP是一种网络协议，所以这个过程中的发布者、消费者和消息代理可以存在于不同的设备上。这是使用消息队列的最佳场所。消息的发布者，即生产者和消息费可以不在同一台设备上，但可以保持通信。AMQP协议是一个二进制协议，具有一些现代特性：多通道、协商、异步、安全、跨平台、中立和高效。AMQP通常分为三层：模型层定义了一组命令（按功能分类），客户端应用程序可以使用这些命令来实现其业务功能。会话层负责将命令从客户端应用程序传递到服务器，然后将服务器的响应传递给客户端应用程序。会话层为这个传输过程提供可靠性、同步机制和错误处理。传输层提供帧处理、信道多路复用、错误检测和数据表示。实现者可以用任何传输协议替换传输层，只要不改变AMQP协议中与客户端应用相关的功能即可。实施者也可以在其他更高级别的协议中使用会话层。AMQP全去百度吧，反正各大博主上来就说AMQP0-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协议中AMQP0-9-1的由来。AMQP模型是由符合AMQP规范的服务器必须提供的关键实体和语义表示的逻辑框架。为了实现本规范中定义的语义，客户端可以发送命令来控制AMQP服务器。其实这是对工作流程的介绍。消息的生产者将消息发送给交换机，交换机接收到消息后，根据不同的路由规则将消息发送到绑定的队列，最后由AMQP代理将消息投递给订阅队列的消费者，或者消费者根据需要自行获取。即从product->exchange->queue->consumer，AMQP也是一个可编程的协议。什么是可编程协议？从某种意义上说，AMQP实体和路由规则是由应用程序本身定义的，而不是由消息代理定义的。这包括对协议本身的操作，如声明队列和交换、定义它们之间的绑定、订阅队列等。虽然这为开发人员提供了自由发挥的空间，但也要求他们了解潜在的定义冲突。当然，这在实践中很少发生，如果发生了，它表现为配置错误。应用程序声明AMQP实体，定义所需的路由方案，或删除不再需要的AMQP实体。至于RabbitMQ中的队列、交换机、路由，就不说了。了解那个东西比了解其他东西更有效。唯一需要注意的是，在发布消息时，发布者可能会指定一些消息属性（也称为消息元数据消息元数据），其中一些用于消息中间件处理消息，其余部分用于让消息消费者对消息中间件完全透明。由于网络不稳定，消息在传输过程中可能会失败。鉴于此，AMQP0-9-1提供了一种消息确认机制messageacknowledgments：当有消息投递给消费者时，消费者向消息中间件发送一个通知Notify来确认消息，无论是自动的还是开发者的自己做。当使用消息确认机制时，只有当消息代理收到通知后，消息或消息组才会从消息队列中移除。在一些特定的情况下，比如当消息无法路由时，消息可能会被返回给消息发布者，或者被删除，或者如果消息代理实现了某种扩展插件，这些无法路由的消息可能会被放置在一个称为死信队列（deathmarkqueue）的队列中，发布者可以通过指定某些特定的消息属性来响应出现这种情况时应该如何处理消息。
