RabbitMQ的应用场景以及基本原理介绍

时间  2019-12-05 标签 rabbitmq 应用 场景 以及 基本原理 介绍

1.背景

RabbitMQ是一个由erlang开发的AMQP(Advanved Message Queue)的开源实现。javascript

2.应用场景

2.1异步处理

场景说明：用户注册后，须要发注册邮件和注册短信,传统的作法有两种1.串行的方式;2.并行的方式
(1)串行方式:将注册信息写入数据库后,发送注册邮件,再发送注册短信,以上三个任务所有完成后才返回给客户端。 这有一个问题是,邮件,短信并非必须的,它只是一个通知,而这种作法让客户端等待没有必要等待的东西.
这里写图片描述
(2)并行方式:将注册信息写入数据库后,发送邮件的同时,发送短信,以上三个任务完成后,返回给客户端,并行的方式能提升处理的时间。
这里写图片描述
假设三个业务节点分别使用50ms,串行方式使用时间150ms,并行使用时间100ms。虽然并性已经提升的处理时间,可是,前面说过,邮件和短信对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功,英爱是写入数据库后就返回.
(3)消息队列
引入消息队列后，把发送邮件,短信不是必须的业务逻辑异步处理
这里写图片描述
由此能够看出,引入消息队列后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间(能够忽略不计),引入消息队列后处理后,响应时间是串行的3倍,是并行的2倍。前端

2.2 应用解耦

场景：双11是购物狂节,用户下单后,订单系统须要通知库存系统,传统的作法就是订单系统调用库存系统的接口.
这里写图片描述
这种作法有一个缺点:java

  • 当库存系统出现故障时,订单就会失败。(这样马云将少赚好多好多钱^ ^)

  • 订单系统和库存系统高耦合.
    引入消息队列
    这里写图片描述web

  • 订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。算法

  • 库存系统:订阅下单的消息,获取下单消息,进行库操做。
    就算库存系统出现故障,消息队列也能保证消息的可靠投递,不会致使消息丢失(马云这下高兴了).

流量削峰

流量削峰通常在秒杀活动中应用普遍
场景:秒杀活动，通常会由于流量过大，致使应用挂掉,为了解决这个问题，通常在应用前端加入消息队列。
做用:
1.能够控制活动人数，超过此必定阀值的订单直接丢弃(我为何秒杀一次都没有成功过呢^^)
2.能够缓解短期的高流量压垮应用(应用程序按本身的最大处理能力获取订单)
这里写图片描述
1.用户的请求,服务器收到以后,首先写入消息队列,加入消息队列长度超过最大值,则直接抛弃用户请求或跳转到错误页面.
2.秒杀业务根据消息队列中的请求信息，再作后续处理. 数据库

3.系统架构

这里写图片描述
几个概念说明:
Broker:它提供一种传输服务,它的角色就是维护一条从生产者到消费者的路线，保证数据能按照指定的方式进行传输,
Exchange：消息交换机,它指定消息按什么规则,路由到哪一个队列。
Queue:消息的载体,每一个消息都会被投到一个或多个队列。
Binding:绑定，它的做用就是把exchange和queue按照路由规则绑定起来.
Routing Key:路由关键字,exchange根据这个关键字进行消息投递。
vhost:虚拟主机,一个broker里能够有多个vhost，用做不一样用户的权限分离。
Producer:消息生产者,就是投递消息的程序.
Consumer:消息消费者,就是接受消息的程序.
Channel:消息通道,在客户端的每一个链接里,可创建多个channel. 编程

4.任务分发机制

4.1Round-robin dispathching循环分发

RabbbitMQ的分发机制很是适合扩展,并且它是专门为并发程序设计的,若是如今load加剧,那么只须要建立更多的Consumer来进行任务处理。安全

4.2Message acknowledgment消息确认

为了保证数据不被丢失,RabbitMQ支持消息确认机制,为了保证数据能被正确处理而不只仅是被Consumer收到,那么咱们不能采用no-ack，而应该是在处理完数据以后发送ack.
在处理完数据以后发送ack,就是告诉RabbitMQ数据已经被接收,处理完成,RabbitMQ能够安全的删除它了.
若是Consumer退出了可是没有发送ack,那么RabbitMQ就会把这个Message发送到下一个Consumer，这样就保证在Consumer异常退出状况下数据也不会丢失.
RabbitMQ它没有用到超时机制.RabbitMQ仅仅经过Consumer的链接中断来确认该Message并无正确处理，也就是说RabbitMQ给了Consumer足够长的时间作数据处理。
若是忘记ack,那么当Consumer退出时,Mesage会从新分发,而后RabbitMQ会占用愈来愈多的内存. 服务器

5.Message durability消息持久化

要持久化队列queue的持久化须要在声明时指定durable=True;
这里要注意,队列的名字必定要是Broker中不存在的,否则不能改变此队列的任何属性.
队列和交换机有一个建立时候指定的标志durable,durable的惟一含义就是具备这个标志的队列和交换机会在重启以后从新创建,它不表示说在队列中的消息会在重启后恢复
消息持久化包括3部分
1. exchange持久化,在声明时指定durable => true架构

hannel.ExchangeDeclare(ExchangeName, "direct", durable: true, autoDelete: false, arguments: null);//声明消息队列，且为可持久化的

2.queue持久化,在声明时指定durable => true 

channel.QueueDeclare(QueueName, durable: true, exclusive: false, autoDelete: false, arguments: null);//声明消息队列，且为可持久化的

3.消息持久化,在投递时指定delivery_mode => 2(1是非持久化).

channel.basicPublish("", queueName, MessageProperties.PERSISTENT_TEXT_PLAIN, msg.getBytes());

若是exchange和queue都是持久化的,那么它们之间的binding也是持久化的,若是exchange和queue二者之间有一个持久化，一个非持久化,则不容许创建绑定.
注意：一旦建立了队列和交换机,就不能修改其标志了,例如,建立了一个non-durable的队列,而后想把它改变成durable的,惟一的办法就是删除这个队列而后重现建立。

6.Fair dispath 公平分发

你可能也注意到了,分发机制不是那么优雅,默认状态下,RabbitMQ将第n个Message分发给第n个Consumer。n是取余后的,它无论Consumer是否还有unacked Message，只是按照这个默认的机制进行分发.
那么若是有个Consumer工做比较重,那么就会致使有的Consumer基本没事可作,有的Consumer却毫无休息的机会,那么,Rabbit是如何处理这种问题呢?
这里写图片描述
经过basic.qos方法设置prefetch_count=1，这样RabbitMQ就会使得每一个Consumer在同一个时间点最多处理一个Message，换句话说,在接收到该Consumer的ack前,它不会将新的Message分发给它

channel.basic_qos(prefetch_count=1)

注意，这种方法可能会致使queue满。固然，这种状况下你可能须要添加更多的Consumer，或者建立更多的virtualHost来细化你的设计。

7.分发到多个Consumer

7.1Exchange

先来温习如下交换机路由的几种类型:
Direct Exchange:直接匹配,经过Exchange名称+RountingKey来发送与接收消息.
Fanout Exchange:广播订阅,向全部的消费者发布消息,可是只有消费者将队列绑定到该路由器才能收到消息,忽略Routing Key.
Topic Exchange：主题匹配订阅,这里的主题指的是RoutingKey,RoutingKey能够采用通配符,如:*或#，RoutingKey命名采用.来分隔多个词,只有消息这将队列绑定到该路由器且指定RoutingKey符合匹配规则时才能收到消息;
Headers Exchange:消息头订阅,消息发布前,为消息定义一个或多个键值对的消息头,而后消费者接收消息同时须要定义相似的键值对请求头:(如:x-mactch=all或者x_match=any)，只有请求头与消息头匹配,才能接收消息,忽略RoutingKey.
默认的exchange:若是用空字符串去声明一个exchange，那么系统就会使用”amq.direct”这个exchange，咱们建立一个queue时,默认的都会有一个和新建queue同名的routingKey绑定到这个默认的exchange上去

channel.BasicPublish("", "TaskQueue", properties, bytes);

由于在第一个参数选择了默认的exchange，而咱们申明的队列叫TaskQueue，因此默认的，它在新建一个也叫TaskQueue的routingKey，并绑定在默认的exchange上，致使了咱们能够在第二个参数routingKey中写TaskQueue，这样它就会找到定义的同名的queue，并把消息放进去。
若是有两个接收程序都是用了同一个的queue和相同的routingKey去绑定direct exchange的话，分发的行为是负载均衡的，也就是说第一个是程序1收到，第二个是程序2收到，以此类推。
若是有两个接收程序用了各自的queue，但使用相同的routingKey去绑定direct exchange的话，分发的行为是复制的，也就是说每一个程序都会收到这个消息的副本。行为至关于fanout类型的exchange。
下面详细来讲:

7.2 Bindings 绑定

绑定其实就是关联了exchange和queue，或者这么说:queue对exchange的内容感兴趣,exchange要把它的Message deliver到queue。

7.3Direct exchange

Driect exchange的路由算法很是简单:经过bindingkey的彻底匹配，能够用下图来讲明.
这里写图片描述
Exchange和两个队列绑定在一块儿,Q1的bindingkey是orange，Q2的binding key是black和green.
当Producer publish key是orange时,exchange会把它放到Q1上,若是是black或green就会到Q2上,其他的Message被丢弃.

7.4 Multiple bindings

多个queue绑定同一个key也是能够的,对于下图的例子,Q1和Q2都绑定了black,对于routing key是black的Message，会被deliver到Q1和Q2，其他的Message都会被丢弃.
这里写图片描述

7.5 Topic exchange

对于Message的routing_key是有限制的，不能使任意的。格式是以点号“.”分割的字符表。好比：”stock.usd.nyse”, “nyse.vmw”, “quick.orange.rabbit”。你能够听任意的key在routing_key中，固然最长不能超过255 bytes。
对于routing_key，有两个特殊字符

  • *(星号)表明任意一个单词

  • #(hash)0个或多个单词
    这里写图片描述
    Producer发送消息时须要设置routing_key，routing_key包含三个单词和连个点号o,第一个key描述了celerity(灵巧),第二个是color(色彩),第三个是物种:
    在这里咱们建立了两个绑定： Q1 的binding key 是”.orange.“； Q2 是 “..rabbit” 和 “lazy.#”：

    • Q1感兴趣全部orange颜色的动物
    • Q2感兴趣全部rabbits和全部的lazy的.
      例子:rounting_key 为 “quick.orange.rabbit”将会发送到Q1和Q2中
      rounting_key 为”lazy.orange.rabbit.hujj.ddd”会被投递到Q2中,#匹配0个或多个单词。

8.消息序列化

RabbitMQ使用ProtoBuf序列化消息,它可做为RabbitMQ的Message的数据格式进行传输,因为是结构化的数据,这样就极大的方便了Consumer的数据高效处理,固然也可使用XML，与XML相比,ProtoBuf有如下优点: 1.简单 2.size小了3-10倍 3.速度快了20-100倍 4.易于编程 6.减小了语义的歧义. ，ProtoBuf具备速度和空间的优点，使得它如今应用很是普遍

联系我们 沪ICP备13005482号-10