RabbitMQ是实现了高级消息队列协议(AMQP)的开源消息代理软件(亦称面向消息的中间件)。AMQP(Advanced Message Queuing Protocol,高级消息队列协议)是一个进程间传递异步消息的网络协议。
![](https://i-blog.csdnimg.cn/blog_migrate/3322a96b44e93d097d7a8f7a0ba6e8f0.png)
工作过程
发布者(Publisher)发布消息(Message),经由交换机(Exchange)。交换机根据路由规则将收到的消息分发给与该交换机绑定的队列(Queue)。最后 AMQP 代理会将消息投递给订阅了此队列的消费者,或者消费者按照需求自行获取
消息投递
Exchange、Queue与Routing Key三个概念是理解RabbitMQ消息投递的关键。RabbitMQ中一个核心的原则是,消息不能直接投递到Queue中。Producer只能将自己的消息投递到Exchange中,由Exchange按照routing_key投递到对应的Queue中,具体的架构参见下图。
![](https://i-blog.csdnimg.cn/blog_migrate/424fc8d08bd8c35219eb55c7d1033a2e.png)
如何完成这三者关系的绑定?总结起来是两点:第一,在Consumer Worker中,声明自己对哪个Exchange感兴趣,并将自己的Queue绑定到自己感兴趣的一组routing_key上,建立相应的映射关系;第二,在Producer中,将消息投递一个Exchange中,并指明它的routing_key。由此可见,Queue这个概念只是对Consumer可见,Producer并不关心消息被投递到哪个Queue中。
消息队列有两种场景
-
生产者消费者:一条消息只能有一个消费者
-
发布者订阅者:一条消息可以被多个消费者收到
消息如果只是存储在队列里是没有任何用处的。被应用消费掉,消息的价值才能够体现。在 AMQP模型中,有两种途径可以达到此目的:
1)将消息投递推送给应用 (“push API”),即称为发布订阅者的模式。
2)应用根据需要主动获取消息 (“pull API”),即称为生产消费者的模式。
使用 push API,应用(application)需要明确表示出它在某个特定队列里所感兴趣的,想要消费的消息。如是,我们可以说应用注册了一个消费者,或者说订阅了一个队列。一个队列可以注册多个消费者,也可以注册一个独享的消费者(当独享消费者存在时,其他消费者即被排除在外)。
生产消费者模式
![](https://i-blog.csdnimg.cn/blog_migrate/f132f336a46af6f955aacdf42da668f4.png)
对于上报的数据,如果是special的行为,需要优先处理。从上图可以看到,数据上报端负责将数据投递到RabbitMQ对应的Exchange,并指明routing_key是common还是special。数据处理端,可以根据情况启多个Woker来消费数据,但至少需要两个,一个用来处理common数据,一个用来处理special的数据。注意:当需要增加多个Worker来消费同一类数据时,需要保持Queue名字一致,比如上面的Common数据。
订阅发布模式
![](https://i-blog.csdnimg.cn/blog_migrate/7b26413750357f935b66b3bb11c6649b.png)
架构如图所示,使用event来作为RabbitMQ的routing key的名字。Event Processor 01对event 01 和event 02感兴趣,则在启动Consumer Worker时,将自己的Queue绑定到这两个routing key上即可,其他Event Processor也是如此,这样便完成了事件的订阅。当有事件发布时,消息便会按照event被投递到对应的Queue中。然后推送到订阅者。