本人花费半年的时间总结的《Java面试指南》已拿腾讯等大厂offer，已开源在github ，欢迎star！
RabbitMQ是采用Erlang语言开发，基于Advanced Message Queuing Protocol （AMQP）开放标准的开发。
Publisher：数据的发送方，生产者。
Consumer：数据的接收方，消费者。
Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。
Queue：消息队列载体，每个消息都会被投入到一个或多个队列。
Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。
Routing Key：路由关键字，exchange根据这个关键字进行消息投递。
vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离(默认的vhost：“/”)。
channel：消息通道，是应用程序（生产与/或消费）和broker之间TCP连接内的虚拟连接，解决TCP连接数量限制及降低TCP连接代价。在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。
Queue主要的属性：
● Name
● Durable (持久化)
● Exclusive (只有一个连接被使用，当连接关闭时队列将被删除)
● Auto-delete (当最后一位消费者退订时，至少有一位消费者的队列被删除)
● Arguments (可选的;由插件和代理特定的功能（如消息TTL，队列长度限制等）使用)
队列名称最多可达255字节的UTF-8字符。
以“amq”开头的队列名称是由 broker 为内部使用而保留的。试图声明一个带有违反此规则的名称的队列，将导致一个 channel-level 异常。
队列在使用之前必须先声明，如果队列不存在，声明一个队列将导致它被创建。如果队列已经存在并且其属性与声明中的相同，则声明不起作用；如果属性不同，则会出现异常（406）。
RabbitMQ中消息传递模型的核心思想是：生产者不直接发送消息到队列。实际的运行环境中，生产者是不知道消息会发送到那个队列上，她只会将消息发送到一个交换器，交换器也像一个生产线，她一边接收生产者发来的消息，另外一边则根据交换规则，将消息放到队列中。交换器必须知道她所接收的消息是什么？它应该被放到那个队列中？它应该被添加到多个队列吗？还是应该丢弃？这些规则都是按照交换器的规则来确定的。
交换器的规则有4种：
topic （主题）
fanout （分发）也有翻译为扇出的。
fanout exchange ：会忽略routing key的存在，广播所有的消息（一个发送到交换机的消息都会被转发到与该交换机绑定的所有队列上）
topic exchange ：将路由键和某模式进行匹配。此时队列需要绑定要一个模式上。符号“#”匹配0个或多个词，符号“*”匹配一个词。因此“audit.#”能够匹配到“audit.irs.corporate”，但是“audit.*” 只会匹配到“audit.irs”。(如果 binding key是 “#”，会接受所有的消息)
direct exchange ： 处理路由键。需要将一个队列绑定到交换机上，要求该消息与一个特定的路由键完全匹配。这是一个完整的匹配（ binding key 和 routing key 一样）。如果一个队列绑定到该交换机上要求路由键 “dog”，则只有被标记为“dog”的消息才被转发，不会转发dog.puppy，也不会转发dog.guard，只会转发dog。
headers exchange ：不同于上面三种Exchange，它是根据Message的一些头部信息来分发过滤Message，忽略routing key的属性，如果Header信息和message消息的头信息相匹配，那么这条消息就匹配上了。
default exchange：默认的Exchange，是一种特别的Direct Exchange。当你手动创建一个队列时，后台会自动将这个队列绑定到一个名称为空的Direct类型交换机上，绑定路由名称与队列名称相同。
负载均衡
默认情况下，RabbitMQ将队列消息随机分配给每个消费者，这时可能出现消息调度不均衡的问题。例如有两台消费者服务器，一个服务器可能非常繁忙，消息不断，另外一个却很悠闲，没有什么负载。RabbitMQ不会主动介入这些情况，还是会随机调度消息到每台服务器。
这是因为RabbitMQ此时只负责调度消息，不会根据ACK的反馈机制来分析那台服务器返回反馈慢，是不是处理不过来啊？
就像下面这个图：
为了解决这个问题，我们可以使用【prefetchcount = 1】这个设置。这个设置告诉RabbitMQ，不要一次将多个消息发送给一个消费者（即在处理并确认前一个消息之前，不会向消费者发送新消息。相反，它会把它分派给下一个不太忙的消费者。）。这样做的好处是只有当消费者处理完成当前消息并反馈后，才会收到另外一条消息或任务。这样就避免了负载不均衡的事情了。消息在消费者之间进行负载均衡，而不是在队列之间进行负载平衡
原文始发于微信公众号（Justin的后端书架）：
