AMQP 0-9-1定义了一些方法，对应了客户端和消息中间件代理之间交互的一些操作方法，这些操作方法的设计跟面向对象编程语言中的方法没有任何共同之处。常用的交换器相关的操作方法有：
exchange.declare
exchange.declare-OK
exchange.delete
exchange.delete-OK
在逻辑上，上面几个操作方法在客户端和消息中间件代理之间的交互如下：
对于队列，也有类似的操作方法：
queue.declare
queue.declare-OK
queue.delete
queue.delete-OK
并非所有的AMQP操作方法都有响应结果操作方法，像消息发布方法basic.publish的使用是最广泛的，此操作方法没有对应的响应结果操作方法。有些操作方法可能有多个响应结果(操作方法)，例如basic.get。
连接(Connection)AMQP的连接(Connection)通常是长期存在的。AMQP是一种使用TCP进行可靠传递的应用程序级协议。AMQP连接使用用户身份验证，可以使用TLS(SSL)进行保护。当应用程序不再需要连接到AMQP代理时，它应该正常关闭AMQP连接，而不是突然关闭底层TCP连接。
通道(Channel)某些应用程序需要与AMQP代理程序建立多个连接。但是，不希望同时打开许多TCP连接，因为这样做会消耗系统资源并使配置防火墙变得十分困难。通道(Channel)可以认为是"共享一个单独的TCP连接的轻量级连接"，一个AMQP连接可以拥有多个通道。
对于使用了多线程处理的应用程序，有一种使用场景十分普遍：每个线程开启一个新的通道使用，这些通道是线程间隔离的。
另外，每个特定的通道和其他通道是相互隔离的，每个执行的AMQP操作方法(包括响应)都携带一个通道的唯一标识，这样客户端就能通过该通道的唯一标识得知操作方法是对应哪个通道发生的。
虚拟主机(Virtual Host)为了使单个消息中间件代理可以托管多个完全隔离的"环境"(这里的隔离指的是用户组、交互器、队列等)，AMQP提供了虚拟主机(Virtual Host)的概念。多个虚拟主机类似于许多主流的Web服务器的虚拟主机，提供了AMQP组件完全隔离的环境。AMQP客户端可以在连接消息中间件代理时指定需要连接的虚拟主机。
个人理解 关于Exchange、Queue和Binding理解RabbitMQ中的AMQP模型，其实从开发者的角度来看，最重要的是Exchange、Queue、Binding三者的关系，这里谈谈个人的见解。消息的发布第一站总是Exchange，从模型上看，消息发布无法直接发送到队列中。Exchange本身不存储消息，它在接收到消息之后，会基于路由规则也就是Binding，把消息路由到目标Queue中。从实际操作来看，声明路由规则总是在发布消息和消费消息之前，也就是一般步骤如下：
1、声明Exchange。
2、声明Queue。
3、基于Exchange和Queue声明Binding，这个过程有可能自定义一个RoutingKey。
4、通过Exchange消息发布，这个过程有可能使用到上一步定义的RoutingKey。
5、通过Queue消费消息。
我们最关注的两个阶段，消息发布和消息消费中，消息发布实际上只跟Exchange有关，而消息消费实际上只跟Queue有关。Binding实际上就是Exchange和Queue的契约关系，会直接影响消息发布阶段的消息路由。那么，路由失败一般是什么情况导致的？路由失败，其实就是消息已经发布到Exchange，而Exchange中从既有的Binding中无法找到存在的目标Queue用于传递消息副本(一般而言，很少人会发送消息到一个不存在的Exchange)。消息路由失败，从理解AMQP的模型来看，可以从根本上避免的，除非是消息发布者故意胡乱使用或者人为错误使用了未存在的RoutingKey、Exchange或者说是Binding关系而导致的。
关于Exchange的类型AMQP-0-9-1模型中支持了四种交换器direct(单播)、fanout(广播)、topic(多播)、headers，实际上，从使用者角度来看，四种交换器的功能是可以相互取代的。例如可以使用fanout类型交换器实现广播，其实使用direct类型交换器也是可以实现广播的，只是对应的direct类型交换器需要通过多个路由键绑定到多个目标队列中。在面对生产环境的技术选型的时候，我们需要考虑性能、维护难度、合理性等角度去考虑选择什么类型的交换器，就上面的广播消息的例子，显然使用fanout类型交换器可以避免声明多个绑定关系，这样在性能、合理性上是更优的选择。
关于负载均衡