RabbitMQ的工作模式及原理
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实现分布式事务?等等。
如果想对RabbitMQ的实战有更多的了解,可以点击下方链接购买《RabbitMQ实战指南》这本书。