有没关于做动画设计师的网站,企业查询宝官网,网络营销外包公司上班,asp网站建设实录初识 RabbitMQ 1.认识 RabbitMQ1.1 介绍1. 2.使用场景1.2.1 推送通知1.2.2 异步任务1.2.3 多平台应用的通信1.2.4 消息延迟1.2.5 远程过程调用 1.3 特性 2.基本概念2.1 生产者、消费者和代理2.2 消息队列2.3 交换机2.3.1 direct2.3.2 topic2.3.3 headers2.3.4 fanout 2.4 绑定2… 初识 RabbitMQ 1.认识 RabbitMQ1.1 介绍1. 2.使用场景1.2.1 推送通知1.2.2 异步任务1.2.3 多平台应用的通信1.2.4 消息延迟1.2.5 远程过程调用 1.3 特性 2.基本概念2.1 生产者、消费者和代理2.2 消息队列2.3 交换机2.3.1 direct2.3.2 topic2.3.3 headers2.3.4 fanout 2.4 绑定2.5 通道2.6 消息确认 1.认识 RabbitMQ
1.1 介绍
RabbitMQ 是开源的 高级消息队列协议Advanced Message Queueing ProtocolAMQP的实现用 Erlang 语言编写支持多种客户端。
RabbitMQ 是目前应用相当广泛的消息中间件其他同类的消息处理中间件有 ActiveMQ、Kafka 等。在企业级应用、微服务应用中RabbitMQ 担当着十分重要的角色。例如在业务服务模块中 解耦、异步通信、高并发限流、超时业务、数据延迟处理 等都可以使用 RabbitMQ。 1. 2.使用场景
1.2.1 推送通知
发布 / 订阅 是 RabbitMQ 的重要功能。可以用 “发布 / 订阅” 功能来实现通知功能。消费者consumer一直监听 RabbitMQ 的数据。如果 RabbitMQ 有数据则消费者会按照 先进先出 规则逐条进行消费。而生产者producer只需要将数据存入 RabbitMQ。这样既降低了不同系统之间的耦合度也确保了消息通知的及时性且不影响系统的性能。
“发布 / 订阅” 功能支持三种模式一对一、一对多、广播。这三种模式都可以根据规则选择分发的对象。众多消费者可以根据规则选择是否接收这些数据扩展性非常强。
1.2.2 异步任务
后台系统接到任务后将其分解成多个小任务只要分别完成这些小任务整个任务便可以完成。但是如果某个小任务很费时且延迟执行并不影响整个任务则可以将该任务放入消息队列中去处理以便加快请求响应时间。
如果用户注册会员时有一项需求发送验证邮件或短信验证码以完成验证则可以使用 RabbitMQ 的消息队列来实现这样可以及时提醒用户操作已经成功。等待收到邮件或验证码然后进行相应的确认即完成验证。
1.2.3 多平台应用的通信
RabbitMQ 可以用于不同开发语言开发的应用间的通信如 Java 开发的应用程序需要与 C 开发的应用程序进行通信实现企业应用集成。由于消息队列是无关平台和语言的而且语义上也不是函数调用因此 RabbitMQ 适合作为多个应用之间的松耦合的接口且不需要发送方和接收方同时在线。
不同语言的软件解耦可以最大限度地减少程序之间的相互依赖提高系统可用性及可扩展性同时还增加了消息的可靠传输和事务管理功能。
RabbitMQ 提供两种事务模式
AMQP 事务模式Confirm 事务模式
1.2.4 消息延迟
利用 RabbitMQ 消息队列延迟功能可以实现订单、支付过期定时取消功能。因为延迟队列存储延时消息所以当消息被发送以后消费者不是立即拿到消息而是等待指定时间后才拿到这个消息进行消费。
当然死信、计时器、定时任务也可以实现延迟或定时功能但是需要开发者去处理。
要实现消息队列延迟功能一般采用官方提供的插件 rabbitmq_delayed_message_exchange 来实现但 RabbitMQ 版本必须是 3.5.8 3.5.8 3.5.8 版本以上才支持该插件。如果低于这个版本则可以利用 死信 来完成。
1.2.5 远程过程调用
在实际的应用场景中有时需要一些同步处理以等待服务器端将消息处理完成后再进行下步处理这相当于 RPCRemote Procedure Call远程过程调用。RabbitMQ 也支持 RPC。
1.3 特性
RabbitMQ 具有以下特性。
信息确认RabbitMQ 有以下两种应答模式。 自动应答当 RabbitMQ 把消息发送到接收端接收端从队列接收消息时会自动发送应答消息给服务器端。手动应答需要开发人员手动调用方法告诉服务器端已经收到。 如果实际场景中对个别消息的丢失不是很敏感则选用自动应答比较理想。如果是一个消息都不能丢的场景则需要选用手动应答在正确处理完以后才应答。如果选择了自动应答那消息重发这个功能就没有了。 队列持久化队列可以被持久化但是否为持久化要看持久化设置。信息持久化设置 properties.DeliveryMode 值即可。默认值为 1 1 1代表不是持久的 2 2 2 代表持久化。消息拒收接收端可以拒收消息而且在发送 reject 命令时可以选择是否要把拒收的消息重新放回队列中。消息的 QoS在接收端设置的。发送端没有任何变化接收端的代码也比较简单只需要加上如 channel.BasicQos(0,1,false); 的代码即可。
2.基本概念
2.1 生产者、消费者和代理
RabbitMQ 的角色有以下三种。
生产者消息的创建者负责创建和推送数据到消息服务器。消费者消息的接收方用于处理数据和确认消息。代理RabbitMQ 本身扮演 “快递” 的角色本身不生产消息。 生产者和消费者并不属于 RabbitMQRabbitMQ 只是为生产者和消费者提供发送和接收消息的 API。 2.2 消息队列
Queue队列是 RabbitMQ 的内部对象用于存储生产者的消息直到发送给消费者也是消费者接收消息的地方。RabbitMQ 中的消息也都只能存储在 Queue 中多个消费者可以订阅同一个Queue。
Queue 有以下一些重要的属性。
持久性如果启用则队列将会在 消息协商器broker重启前都有效。自动删除如果启用则队列将会在所有的消费者停止使用之后自动删除掉。惰性如果没有声明队列则应用程序调用队列时会导致异常并不会主动声明。排他性如果启用则声明它的消费者才能使用。
2.3 交换机
Exchange交换机用于接收、分配消息。生产者先要指定一个 routing key然后将消息发送到交换机。这个 routing key 需要与 ExchangeType 及 binding key 联合使用才能最终生效然后交换机将消息路由到一个或多个 Queue 中或丢弃。
在虚拟主机的消息协商器broker中每个 Exchange 都有唯一的名字。
Exchange 包含 4 4 4 种类型direct、topic、fanout、headers。不同的类型代表绑定到队列的行为不同。 AMQP 规范里还有两种交换机类型system 与 自定义。 2.3.1 direct
direct 类型的行为是 “先匹配再投送”。在绑定队列时会设定一个 routing key只有在消息的 routing key 与队列匹配时消息才会被交换机投送到绑定的队列中。允许一个队列通过一个固定的 routing key通常是队列的名字进行绑定。Direct 交换机将消息根据其 routing key 属性投递到包含对应 key 属性的绑定器上。
Direct Exchange 是 RabbitMQ 默认的交换机模式也是最简单的模式。它根据 routing key 全文匹配去寻找队列。
2.3.2 topic
按规则转发消息最灵活。主题交换机topic exchange转发消息主要根据通配符。队列和交换机的绑定会定义一种路由模式通配符就要在这种路由模式和路由键之间匹配后交换机才能转发消息。
在这种交换机模式下路由键必须是一串字符用 . 隔开。
路由模式必须包含一个星号 *主要用于匹配路由键指定位置的一个单词。
topic 还支持消息的 routing key用 * 或 # 的模式进行绑定。* 匹配一个单词# 匹配 0 0 0 个或多个单词。例如binding key *.user.# 匹配 routing key 为cn.user 和 us.user.db但是不匹配 user.hello。
2.3.3 headers
它根据应用程序消息的特定属性进行匹配可以在 binding key 中标记消息为可选或必选。在队列与交换机绑定时会设定一组键值对规则。消息中也包括一组键值对headers 属性当这些键值对中有一对或全部匹配时消息被投送到对应队列。
2.3.4 fanout
消息广播的模式即将消息广播到所有绑定到它的队列中而不考虑 routing key 的值不管路由键或是路由模式。如果配置了 routing key则 routing key 依然会被忽略。
2.4 绑定
RabbitMQ 中通过绑定binding将 Exchange 与 Queue 关联起来。这样 RabbitMQ 就知道如何正确地将消息路由到指定的 Queue 了。
在绑定 Exchange 与 Queue 时一般会指定一个 binding key。消费者将消息发送给 Exchang 时一般会指定一个 routing key。如果 binding key 与 routing key 相匹配则消息将会被路由对应的 Queue 中。
绑定是生产者和消费者消息传递的连接。生产者发送消息到 Exchange消费者从 Queue 接收消息都是根据绑定来执行的。 2.5 通道
有些应用需要与 AMQP 代理建立多个连接。但同时开启多个 TCPTransmission Control Protocol传输控制协议连接会消耗过多的系统资源并使得防火墙的配置变得更加困难。AMQP 0-9-1 协议用 通道channel来处理多连接可以把通道理解成 共享一个 TCP 连接的多个轻量化连接。 一个特定通道上的通信与其他通道上的通信是完全隔离的因此每个 AMQP 方法都需要携带一个通道号。这样客户端就可以指定此方法是为哪个通道准备的。
2.6 消息确认
消息确认message acknowledgement是指当一个消息从队列中投递给消费者consumer后消费者会通知一下消息代理broker这个过程可以是自动的也可以由处理消息的应用的开发者执行。当 “消息确认” 启用时消息代理需要收到来自消费者的确认回执后才完全将消息从队列中删除。
如果消息无法被成功路由或被返给发送者并被丢弃或消息代理执行了延期操作则消息会被放入一个 死信 队列中。此时消息发送者可以选择某些参数来处理这些特殊情况。
