分布式消息队列RabbitMQ之一:基本概念理解

许多新手在刚接触RabbitMQ的时候，会被各种名词弄晕，包括ConnectionFactory 、Connection 、Channel、Exchange、Queue、RoutingKey、BindingKey等等，现在我言简意赅的描绘一下这些名词到底是啥概念

首先我们肯定知道RabbitMQ就是消息队列的一种实现，那么围绕这个，我们就可以思考一个消息队列到底需要什么，当然是需要队列，那么这个队列就是Queue，那么其他的所有名词都是围绕这个Queue来拓展的。

首先，想要让队列不在本地运行，而在网络中运行，肯定会有连接这个概念，所以就会有Connection，我们发一条消息连接一次，这样很显然是浪费资源的，建立连接的过程也很耗时，所以我们就会做一个东西让他来管理连接，当我用的时候，直接从里边拿出来已经建立好的连接发信息，那么ConnectionFactory应运而生。

接下来，当程序开发时，可能不止用到一个队列，可能有订单的队列、消息的队列、任务的队列等等，那么就需要给不同的queue发信息，那么和每一个队列连接的这个概念，就叫Channel

再往下来，当我们开发的时候还有时候会用到这样一种功能，就是当我发送一条消息，需要让几个queue都收到，那么怎么解决这个问题呢，难道我要给每一个queue发送一次消息？那岂不是浪费带宽又浪费资源，我们能想到什么办法呢，当然是我们发送给RabbitMQ服务器一次，然后让RabbitMQ服务器自己解析需要给哪个Queue发，那么Exchange就是干这件事的

但是我们给Exchange发消息，他怎么知道给哪个Queue发呢？这里就用到了RoutingKey和BindingKey

BindingKey是Exchange和Queue绑定的规则描述，这个描述用来解析当Exchange接收到消息时，Exchange接收到的消息会带有RoutingKey这个字段，Exchange就是根据这个RoutingKey和当前Exchange所有绑定的BindingKey做匹配，如果满足要求，就往BindingKey所绑定的Queue发送消息，这样我们就解决了我们向RabbitMQ发送一次消息，可以分发到不同的Queue的过程

至此，我们就把所有的名词贯通咯，接下来做个概要描述：

ConnectionFactory：与RabbitMQ服务器连接的管理器

Connection：与RabbitMQ服务器的连接

Channel：与Exchange的连接

Exchange：接受消息提供者（生产者）的消息，并根据消息的RoutingKey和Exchange绑定的BindingKey分配消息

Queue：存储消息接收者（消费者）的消息

RoutingKey：指定当前消息被谁接受

BindingKey：指定当前Exchange下，什么样的RoutingKey会被下派到当前绑定的Queue中

如下图（本人画画功底薄，别见怪~）

其中我们看到BindingKey1有两个，这样不会冲突，因为消息具体发送到哪里是通过Exchange和RoutingKey来决定的

也就是说我指定Channel1-->Exchange1-->BindingKey1就会被发送到Queue1中

当我指定Channel-2-->Exchange2-->bindingKey1则会发送到Queue2和Queue3中

温馨提示：当前的RoutingKey和BindingKey均为参数名称，不是参数真实值，那么真实情况下是下方这样的：

创建ConnectionFactory，通过ConnectionFactory创建Connection，通过Connection创建Channel

通过channel，声明一个Exchange名字为“Exchange2”，声明一个Queue名字为“Queue2”，声明一个Queue名字为“Queue3”

声明完了，我们就需要让他们绑定了，让“Exchange2”绑定到“Queue2”上，设置绑定的RoutingKey（真实情况下参数名都是RoutingKey，没有BindingKey这个参数，为了区别用户发送的和我们绑定的概念，我们才说RoutingKey和BindingKey）为“key1”，在让“Exchange2”绑定到“Queue2”上，设置绑定的RoutingKey为“key1”，然后通过Channel发送消息，发送消息的三个参数Exchange名称、RoutingKey，和消息，Exchange名称就是“Exchange2”，RoutingKey就是“key1”，那么这样这条消息就会被成功发送到“Queue2”和“Queue3”中了，OK大功告成！

http://blog.csdn.net/xinbaobaoer/article/details/54907793