RabbitMQ的5大核心概念
在上篇文章Linux安装Erlang和RabbitMQ详细步骤中我们已经安装好了RabbitMQ，并且最后也通过web页面看到了它的一个管理界面。在管理界面中，可以看到有很多选项：
这些选项是什么意思呢？它们是用来干什么的呢？这就是本篇文章要讲的RabbitMQ的5大核心概念：Connection（连接）、Channel（信道）、Exchange（交换机）、Queue（队列）、Virtual host（虚拟主机）。
在介绍这些概念之前，我们先看一张图，图中展示的是RabbitMQ的工作模型，根据这张图，下面理解起来就比较容易了：
其中，中间的Broker表示RabbitMQ服务，每个Broker里面至少有一个Virtual host虚拟主机，每个虚拟主机中有自己的Exchange交换机、Queue队列以及Exchange交换机与Queue队列之间的绑定关系Binding。producer（生产者）和consumer（消费者）通过与Broker建立Connection来保持连接，然后在Connection的基础上建立若干Channel信道，用来发送与接收消息。
Connection（连接）
每个producer（生产者）或者consumer（消费者）要通过RabbitMQ发送与消费消息，首先就要与RabbitMQ建立连接，这个连接就是Connection。Connection是一个TCP长连接。
Channel（信道）
Channel是在Connection的基础上建立的虚拟连接，RabbitMQ中大部分的操作都是使用Channel完成的，比如：声明Queue、声明Exchange、发布消息、消费消息等。
看到此处，你是否有这样一个疑问：既然已经有了Connection，我们完全可以使用Connection完成Channel的工作，为什么还要引入Channel这样一个虚拟连接的概念呢？因为现在的程序都是支持多线程的，如果没有Channel，那么每个线程在访问RabbitMQ时都要建立一个Connection这样的TCP连接，对于操作系统来说，建立和销毁TCP连接是非常大的开销，在系统访问流量高峰时，会严重影响系统性能。
Channel就是为了解决这种问题，通常情况下，每个线程创建单独的Channel进行通讯，每个Channel都有自己的channel id帮助Broker和客户端识别Channel，所以Channel之间是完全隔离的。
Connection与Channel之间的关系可以比作光纤电缆，如果把Connection比作一条光纤电缆，那么Channel就相当于是电缆中的一束光纤。
Virtual host（虚拟主机）
Virtual host是一个虚拟主机的概念，一个Broker中可以有多个Virtual host，每个Virtual host都有一套自己的Exchange和Queue，同一个Virtual host中的Exchange和Queue不能重名，不同的Virtual host中的Exchange和Queue名字可以一样。这样，不同的用户在访问同一个RabbitMQ Broker时，可以创建自己单独的Virtual host，然后在自己的Virtual host中创建Exchange和Queue，很好地做到了不同用户之间相互隔离的效果。
Queue（队列）
Queue是一个用来存放消息的队列，生产者发送的消息会被放到Queue中，消费者消费消息时也是从Queue中取走消息。
Exchange（交换机）
Exchange是一个比较重要的概念，它是消息到达RabbitMQ的第一站，主要负责根据不同的分发规则将消息分发到不同的Queue，供订阅了相关Queue的消费者消费到指定的消息。那Exchange有哪些分发消息的规则呢？这就要说到Exchange的4种类型了：direct、fanout、topic、headers。
在介绍这4种类型的Exchange之前，我们先来了解一下另外一个比较重要的概念：Routing key，翻译成中文就是路由键。当我们创建好Exchange和Queue之后，需要使用Routing key（通常叫作Binding key）将它们绑定起来，producer在向Exchange发送一条消息的时候，必须指定一个Routing key，然后Exchange接收到这条消息之后，会解析Routing key，然后根据Exchange和Queue的绑定规则，将消息分发到符合规则的Queue中。
接下来，我们根据上面的流程再来详细介绍下4种类型的Exchange。
1、direct
direct的意思是直接的，direct类型的Exchange会将消息转发到指定Routing key的Queue上，Routing key的解析规则为精确匹配。也就是只有当producer发送的消息的Routing key与某个Binding key相等时，消息才会被分发到对应的Queue上。
比如我们现在有一个direct类型的Exchange，它下面绑定了三个Queue，Binding key分别是ORDER/GOODS/STOCK：
然后我们向该Exchange中发送一条消息，消息的Routing key是ORDER：
按照规则分析，这条消息应该被路由到MY_EXCHANGE_ORDER_QUEUE这个Queue。消息发送成功之后，我们去Queues中查看，发现确实只有MY_EXCHANGE_ORDER_QUEUE这个QUEUE接收到了一条消息。
进入这个队列，通过getMessage取出消息查看，确实是我们刚才手动发送的那条消息。
所以，direct类型的Exchange在分发消息时，必须保证producer发送消息的Routing key与Exchange和Queue绑定的Binding key相等才可以。
2、fanout
fanout是扇形的意思，该类型通常叫作广播类型。fanout类型的Exchange不处理Routing key，而是会将发送给它的消息路由到所有与它绑定的Queue上。
比如我们现在有一个fanout类型的Exchange，它下面绑定了三个Queue，Binding key分别是ORDER/GOODS/STOCK：
然后我们向该Exchange中发送一条消息，消息的Routing key随便填一个值abc：
按照规则分析，这条消息应该被路由到所有与该Exchange绑定的Queue，即三个Queue都应该会受到消息。消息发送成功之后，我们去Queues中查看，发现确实每个QUEUE都接收到了一条消息。
进入这三个QUEUE，通过getMessage取出消息查看，确实是我们刚才手动发送的那条消息。
所以，fanout类型的Exchange不管Routing key是什么，它都会将接收到的消息分发给所有与自己绑定了的Queue上。
3、topic
topic的意思是主题，topic类型的Exchange会根据通配符对Routing key进行匹配，只要Routing key满足某个通配符的条件，就会被路由到对应的Queue上。通配符的匹配规则如下：
● Routing key必须是一串字符串，每个单词用“.”分隔；
● 符号“#”表示匹配一个或多个单词；
● 符号“*”表示匹配一个单词。
例如：“*.123” 能够匹配到 “abc.123”，但匹配不到 “abc.def.123”；“#.123” 既能够匹配到 “abc.123”，也能匹配到 “abc.def.123”。
比如我们现在有一个topic类型的Exchange，它下面绑定了4个Queue，Binding key分别是 .ORDER、GOODS.、#.STOCK、USER.#。
然后我们向该Exchange中发送一条消息，消息的Routing key为：USER.ABC.ORDER。
按照规则分析，USER.ABC.ORDER这个Routing key只可以匹配到 “USER.#” ，所以，这条消息应该被路由到MY_TOPIC_USER_QUEUE这个Queue中。消息发送成功之后，我们去Queues中查看，发现结果符合我们的预期。
进入这个QUEUE，通过getMessage取出消息查看，确实是我们刚才手动发送的那条消息。
4、headers
日常工作中，以上三种类型的Exchange已经能够满足我们基本上所有的需求了，headers模式并不经常使用，我们只需要对headers Exchange有一个基本的了解就可以了。
headers Exchange中，Exchange与Queue之间的绑定不再通过Binding key绑定，而是通过Arguments绑定。比如我们现在有一个headers类型的Exchange，下面通过不同的Arguments绑定了三个Queue：
producer在发送消息时可以添加headers属性，Exchange接收到消息后，会解析headers属性，只要我们上面配置的Arguments中的所有属性全部被包含在Headers中并且值相等，那么这条消息就会被路由到对应的Queue中。
比如我们向上面的Exchange中发送一条消息，消息的Headers中添加“x=1”：
根据规则，只有queue1这个队列满足x=1的条件，queue2中的y=2条件不满足，所以，消息应该只被路由到queue1队列中。消息发送成功后，我们可以看到queue1确实收到了消息：
并且这条消息就是我们刚才手动发送的消息：
然后我们再发送一条消息，消息的headers中有两个属性：x=1，y=2：
根据规则，queue1的x=1的条件满足，queue2的x=1、y=2的条件满足，queue3的y=2的条件满足，所以，这三个Queue应该都能够收到这条消息。消息发送成功后，结果符合预期：
这条消息就是我们刚才手动发送的消息：
看到这里，我们已经对RabbitMQ的核心概念有了清晰的理解，并且对它们的工作模式也都探索清楚了，后续文章我会继续整理RabbitMQ系列的相关内容及项目中的实战使用，比如如何使用RabbitMQ实现订单超时未支付自动取消订单？如何使用RabbitMQ实现分布式事务？等等。