消息队列RabbitMQ

消息队列RabbitMQ

 

消息队列

    消息(Message)是指在应用间传送的数据。消息能够很是简单,好比只包含文本字符串,也能够更复杂,可能包含嵌入对象。
  消息队列(Message Queue)是一种应用间的通讯方式,消息发送后能够当即返回,由消息系统来确保消息的可靠传递。消息发布者只管把消息发布到 MQ 中而不用管谁来取,消息使用者只管从 MQ 中取消息而不论是谁发布的。这样发布者和使用者都不用知道对方的存在。

  

消息队列的使用场景

  从上面的描述中能够看出消息队列是一种应用间的异步协做机制,那何时须要使用 MQ 呢?
以常见的订单系统为例,用户点击【下单】按钮以后的业务逻辑可能包括:扣减库存、生成相应单据、发红包、发短信通知。在业务发展初期这些逻辑可能放在一块儿同步执行,随着业务的发展订单量增加,须要提高系统服务的性能,这时能够将一些不须要当即生效的操做拆分出来异步执行,好比发放红包、
发短信通知等。这种场景下就能够用 MQ ,在下单的主流程(好比扣减库存、生成相应单据)完成以后发送一条消息到 MQ 让主流程快速完结,而由另外的单独线程拉取MQ的消息(或者由 MQ 推送消息),当发现 MQ 中有发红包或发短信之类的消息时,执行相应的业务逻辑。 以上是用于业务解耦的状况,其它常见场景包括最终一致性、广播、错峰流控等等。

  

 

RabbitMQ 特色

RabbitMQ 是一个由 Erlang 语言开发的 AMQP 的开源实现。
AMQP :Advanced Message Queue,高级消息队列协议。它是应用层协议的一个开放标准,为面向消息的中间件设计,基于此协议的客户端与消息中间件可传递消息,并不受产品、开发语言等条件的限制。
RabbitMQ 最初起源于金融系统,用于在分布式系统中存储转发消息,在易用性、扩展性、高可用性等方面表现不俗。具体特色包括: 可靠性(Reliability) RabbitMQ 使用一些机制来保证可靠性,如持久化、传输确认、发布确认。
灵活的路由(Flexible Routing) 在消息进入队列以前,经过 Exchange 来路由消息的。对于典型的路由功能,RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能,能够将多个 Exchange 绑定在一块儿,也经过插件机制实现本身的 Exchange 。
消息集群(Clustering) 多个 RabbitMQ 服务器能够组成一个集群,造成一个逻辑 Broker 。 高可用(Highly Available Queues) 队列能够在集群中的机器上进行镜像,使得在部分节点出问题的状况下队列仍然可用。 多种协议(Multi-protocol) RabbitMQ 支持多种消息队列协议,好比 STOMP、MQTT 等等。 多语言客户端(Many Clients) RabbitMQ 几乎支持全部经常使用语言,好比 Java、.NET、Ruby 等等。 管理界面(Management UI) RabbitMQ 提供了一个易用的用户界面,使得用户能够监控和管理消息 Broker 的许多方面。 跟踪机制(Tracing) 若是消息异常,RabbitMQ 提供了消息跟踪机制,使用者能够找出发生了什么。
插件机制(Plugin System) RabbitMQ 提供了许多插件,来从多方面进行扩展,也能够编写本身的插件。

  

 

生产者与消费者

RabbitMQ是为了应用程序与应用程序之间的通讯
RabbitMQ是消息投递服务,RabbitMQ在应用程序之间扮演路由器的角色
应用程序能够发送信息,发送消息给RabbitMQ(代理服务器)
应用程序能够接收信息,从RabbitMQ(代理服务器)接收信息
当一个应用程序链接到RabbitMQ时,它只有一个身份,要么是生产者,或者消费者。

生产者建立消息,而后发布到代理服务器RabbitMQ,消息包含两部分:有效载荷与标签。
消费者链接到代理服务器,并订阅到队列上,咱们能够把消息队列想象成一个具体邮箱,每当消息到达特定的邮箱时,RabbitMQ会将其发送给其中一个订阅/监听的消费者。

注意:消费者接收消息里面只有有效载荷,没有消息的标签,RabbitMQ不会告诉你是谁是消息的生产者,就好像你拿着一封信,上面并无署名。

整个消息传递的过程:生产者建立消息,消费者接收消息,二者是能够切换的。

  

 

 RabbitMQ 内部结构

·  Message
消息,消息是不具名的,它由消息头和消息体组成。消息体是不透明的,而消息头则由一系列的可选属性组成,这些属性包括routing-key(路由键)、priority(相对于其余消息的优先权)、delivery-mode(指出该消息可能须要持久性存储)等。
·  Publisher
消息的生产者,也是一个向交换器发布消息的客户端应用程序。
·  Exchange
交换器,用来接收生产者发送的消息并将这些消息路由给服务器中的队列。
·  Binding
绑定,用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列链接起来的路由规则,因此能够将交换器理解成一个由绑定构成的路由表。
·  Queue
消息队列,用来保存消息直到发送给消费者。它是消息的容器,也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面,等待消费者链接到这个队列将其取走。
·  Connection
网络链接,好比一个TCP链接。
·  Channel
信道,多路复用链接中的一条独立的双向数据流通道。信道是创建在真实的TCP链接内地虚拟链接,AMQP 命令都是经过信道发出去的,不论是发布消息、订阅队列仍是接收消息,这些动做都是经过信道完成。由于对于操做系统来讲创建和销毁 TCP 都是很是昂贵的开销,因此引入了信道的概念,以复用一条 TCP 链接。
·  Consumer
消息的消费者,表示一个从消息队列中取得消息的客户端应用程序。
·  Virtual Host
虚拟主机,表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每一个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器,拥有本身的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础,必须在链接时指定,RabbitMQ 默认的 vhost 是 / 。
·  Broker
表示消息队列服务器实体。

  

应用程序与代理服务器的通讯机制

AMQP:
AMQP,高级消息队列协议,以解决众多的消息队列需求和拓扑结构问题
而RabbitMQ是惟一实现了AMQP标准的代理服务器

信道:
生产者和消费者都须要链接到RabbitMQ,才能消费或者发布消息。

应用程序与RabbitMQ之间创建一条TCP链接,在TCP链接上就能够建立一条AMOP信道,信道是创建在TCP链接内的虚拟链接。

每一条信道都由一个惟一标识的ID(AMQP库会帮你记住ID),发布消息,订阅队列、接收消息都是在信道里完成的。

信道存在的意义:
咱们知道创建和销毁TCP会话是很昂贵的开销,好比如今发送者大量的发送消息给RabbitMQ,若是如今每条信息发送都是一个线程来发送信息,难道每一个线程发送信息都须要与RabbitMQ创建一条TCP链接吗?

这里面就有了一种办法:在现成的TCP链接上创建信道,信道与信道之间相互独立,不会给操做系统的TCP栈形成额外负担,在一条TCP链接上建立信道是没有限制的,因此这里使用信道能够建立并行的传输层,不会受到TCP层的链接限制。

 

AMQP消息路由:队列、交换器和绑定

AMQP 中增长了 Exchange 和 Binding 的角色。生产者把消息发布到 Exchange 上,消息最终到达队列并被消费者接收,而 Binding 决定交换器的消息应该发送到那个队列。

AMQP 的消息路由过程

队列

队列:消息最终到达队列中并等待消费。
消费者经过两种方式从队列中接收消息:
(1)
AMQP的basic.consume命令订阅。
将信道置为接收模式,直到取消队列的订阅为止,订阅了队列,消费者(或者拒绝)最近接收的消息后,就能从队列中自动接收下一条消息。若是消费者处理队列消息,而且须要消息一到达队列就自动接收的话,使用basic.consume,说白了就是持续接收信息。

(2)
AMQP的basic.get命令订阅
只想从队列中得到单条消息而不是持续的订阅。总结:basic.get命令会订阅队列,得到单条消息,而后取消订阅,因此消费者应该使用basic.consume来实现高吞吐量

若是只有一个消费者订阅了队列,消息会当即发送给这个订阅者。
若是没有消费者订阅队列,消息会在队列里等待,一旦有消费者订阅了对了,那么队列上的消息就会发送给消费者
若是有多个消费者订阅到同一个队列上,消息是如何分发的?循环依次发送给消费者,一次只发送给一个消费者。

 

交换器和绑定

消息实际上投递到的是交换机,而后根据肯定的规则,RabbitMQ将会决定消息该投递到哪一个队列,这些规则被称为路由键,队列经过路由键绑定到交换器。

  当你发消息到代理服务器时,即使路由键是空的,RabbitMQ也会将其和使用的路由键进行匹配。若是路由的消息不匹配任何绑定模式,消息将会进入黑洞。
交换机在队列与消息中间起到了中间层的做用,有了交换机咱们能够实现更灵活的功能,RabbitMQ中有三种经常使用的交换机类型:
direct: 若是路由键匹配,消息就投递到对应的队列
fanout:投递消息给全部绑定在当前交换机上面的队列
topic:容许实现有趣的消息通讯场景,使得5不一样源头的消息可以达到同一个队列。topic队列名称有两个特殊的关键字。
o* 能够替换一个单词
o# 能够替换全部的单词
能够理解,direct为1v1, fanout为1v全部,topic比较灵活,能够1v任意。

 

(交换机)Exchange 类型

Exchange分发消息时根据类型的不一样分发策略有区别,目前共四种类型:direct、fanout、topic、headers 。headers 匹配 AMQP 消息的 header 而不是路由键,此外 headers 交换器和 direct 交换器彻底一致,但性能差不少,目前几乎用不到了,因此直接看另外三种类型:

direct

消息中的路由键(routing key)若是和 Binding 中的 binding key 一致, 交换器就将消息发到对应的队列中。路由键与队列名彻底匹配,若是一个队列绑定到交换机要求路由键为“dog”,则只转发 routing key 标记为“dog”的消息,不会转发“dog.puppy”,也不会转发“dog.guard”等等。它是彻底匹配、单播的模式。

fanout

每一个发到 fanout 类型交换器的消息都会分到全部绑定的队列上去。fanout 交换器不处理路由键,只是简单的将队列绑定到交换器上,每一个发送到交换器的消息都会被转发到与该交换器绑定的全部队列上。很像子网广播,每台子网内的主机都得到了一份复制的消息。fanout 类型转发消息是最快的。

 

topic

topic 交换器经过模式匹配分配消息的路由键属性,将路由键和某个模式进行匹配,此时队列须要绑定到一个模式上。它将路由键和绑定键的字符串切分红单词,这些单词之间用点隔开。它一样也会识别两个通配符:符号“#”和符号“”。#匹配0个或多个单词,匹配很少很多一个单词。

 

 

虚拟主机与隔离

每个vhost本质都是一个mini版的Rabbitmq服务器,拥有本身的队列、交换器和绑定,还拥有本身的权限机制安全

 

Vhost与Rabbit就像虚拟机与物理服务器同样。bash

它们经过在各自实例间提供逻辑分离,容许你为不一样的应用程序安全保密运行数据。服务器

这颇有用,它能将同一个Rabbit的众多客户区分开来,又能够避免队列和交换器的命名冲突。不然你可能不得不运行多个Rabbit,这将带来更多管理问题,相反,你能够只运行一个Rabbit,而后按需启动或关闭vhost。网络

 

当你在Rabbit里建立一个用户,用户一般会被指派给至少一个vhost,而且只能访问被指派vhost内的队列、交换器和绑定。Vhost之间是相互隔离的架构

你将没法将vhost banana_tree上的交换器绑定到vhostoak_tree中的队列去。这确保了安全性与可移植性。异步

 

注意:当你在RabbitMQ集群上建立vhost,整个集群上都会建立该vhost,vhost不只消除了基础架构中每一层运行一个RabbitMQ服务器的须要,一样避免了为每一层建立不一样的集群。分布式

建立vhost:rabbitmqctl add_vhost [vhost_name]
删除vhost:rabbitmqctl delete_vhost [vhost_name]
查看服务器运行的vhost:rabbitmqctl list_vhost
相关文章
相关标签/搜索