MQ学习记录

1. MQ的基本概念

1. MQ概述

MQ全称Message Queue(消息队列),是在消息的传输过程中保存消息的容器。多用于分布式系统之间进行通信。
MQ概述图

2. MQ的优势

2.1 应用解耦

系统依赖图
引入MQ前系统弊端

  • 系统的耦合性越高,容错性就越低
    以上是一个传统系统的架构图,服务之间高度耦合,若库存系统崩溃,则订单系统对库存系统的请求不通,间接导致订单系统与别的系统之间交互失败,整个系统奔溃。
  • 可维护性越低
    如果需要增加新的系统,则订单系统的代码也需要修改,拓展性不高。

引入MQ后的系统依赖图
引入MQ后系统后

  • 应用间解耦,提升容错性和可维护性
    库存等系统都与MQ进行交互,不与订单系统直接交互,应用间解耦。

2.2 异步提速

  • 提升用户体验和系统吞吐量(单位时间内处理请求的数目)

未引入MQ前系统耗时
备注:系统的设计是基于同步场景下考虑的。
引入MQ前一个下单操作耗时:
20+100+100+100=320ms
用户点击下单按钮后,需要等待320ms才能得到下单响应,耗时较多,体验较差。

引入MQ后系统耗时
引入MQ系统后一个下单操作耗时:
用户点击下单按钮后,只需等待20+5=25ms,就能得到下单响应。
因为订单系统只需要与DB以及MQ系统交互即可。而此时可以开启三个MQ(MQ内部也是队列,请求也是按顺序处理)来处理三个请求,达到异步提速。

2.3 削峰填谷

  • 提升系统稳定性

引入MQ前的请求

假如高峰期,每秒并发请求数量突暴增到 5000条。系统每秒处理1000请求,如果每秒请求到 5k 的话,可能就直接系统给打死了,导致系统崩溃,用户也就没法再使用系统了。
引入MQ后的请求

这个时候如果使用MQ,每秒中由5k个请求写入MQ中,系统每一秒处理1000个请求,A系统慢慢的拉去请求,这个时候,系统就能够在自己的承受范围之内,哪怕是高峰期也不会挂掉。使用了 MQ 之后,限制消费消息的速度为1000,这样一来,高峰期产生的数据势必会被积压在 MQ 中,高峰就被“削”掉了,MQ承受请求能力较强,但是因为消息积压,在高峰期过后的一段时间内,消费消息的速度还是会维持在1000,直到消费完积压的消息,这就叫做“填谷”。

削峰填谷

3 MQ的劣势

3.1 系统可用性降低

系统引入的外部依赖越多,系统稳定性越差。一旦MQ宕机,就会对业务造成影响。

  • 那么问题来了,如何保证MQ的高可用?

3.2 系统复杂度提高

MQ的加入大大增加了系统的复杂度,以前系统间是同步的远程调用,现在是通过MQ进行异步调用。

  • 那么问题来了,如何保证消息不被丢失等情况?

4 常见的MQ产品

RabbitMQActiveMQRocketMQKafka
公司/社区RabbitApache阿里Apache
开发语言ErlangJavaJavaScala&Java
协议支持AMQP,XMPP,SMTP,
STOMP
OpenWire,STOMP,REST,XMPP,AMQP自定义自定义协议,社区封装了http协议支持
客户端支持语言官方支持Erlang,Java,
Ruby等,社区产出多种API,几乎支持所有语言
Java,C,C++,
Python,PHP,
Perl,.net等
Java,C++
(不成熟)
官方支持Java,社区产出
多种API,如PHP,Python等
单机吞吐量万级(其次)万级(最差)十万级(最好)十万级(次之)
消息延迟微秒级毫秒级毫秒级毫秒以内
功能特性并发能力强,性能及其好,
延时滴,社区活跃,管理
界面丰富
老牌产品,成熟度高,
文档较多
MQ功能比较完备,扩展性佳只支持主要的MQ功能,
毕竟是为大数据领域准备的。

5 RabbitMQ 简介

AMQP,即 Advanced Message Queuing Protocol(高级消息队列协议),是一个网络协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息,并不受客户端/中间件不同产品,不同的开发语言等条件的限制。2006年,AMQP 规范发布。类比HTTP

5.1 AMOP的协议模型

协议模型图

正如图中所看到的,AMQP协议模型有三部分组成:生产者、消费者和服务端。

  • 生产者:投递消息的一方,首先连接到Server,建立一个连接,开启一个信道;然后生产者声明交换器和队列,设置相关属性,并通过路由键将交换器和队列进行绑定。
  • 消费者:需要进行建立连接,开启信道等操作,便于接收消息。

接着生产者就可以发送消息,发送到服务端中的虚拟主机,虚拟主机中的交换器根据路由键选择路由规则,然后发送到不同的消息队列中,这样订阅了消息队列的消费者就可以获取到消息,进行消费。最后还要关闭信道和连接。

5.2 RabbitMQ协议模型

RabbitMQ是基于AMQP协议实现的,其结构如下图所示,和AMQP协议简直就是一模一样。
RabbitMQ结构图

5.3 RabbitMQ 相关概念

  • Broker:接收和分发消息的应用,RabbitMQ Server就是 Message Broker
  • Virtual host:出于多租户和安全因素设计的,把 AMQP 的基本组件划分到一个虚拟的分组中,类似于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务时,可以划分出多个vhost,每个用户在自己的 vhost 创建 exchange/queue 等
  • Connection:publisher/consumer 和 broker 之间的 TCP 连接
  • Channel:如果每一次访问 RabbitMQ 都建立一个 Connection,在消息量大的时候建立 TCP Connection的开销将是巨大的,效率也较低。Channel 是在 connection 内部建立的逻辑连接,如果应用程序支持多线程,通常每个thread创建单独的 channel 进行通讯,AMQP method 包含了channel id 帮助客户端和message broker 识别 channel,所以 channel 之间是完全隔离的。Channel 作为轻量级的 Connection 极大减少了操作系统建立 TCP connection 的开销
  • Exchange:message 到达 broker 的第一站,根据分发规则,匹配查询表中的 routing key,分发消息到queue 中去。常用的类型有:direct (point-to-point), topic (publish-subscribe) and fanout (multicast)
  • Queue:消息最终被送到这里等待 consumer 取走
  • Binding:exchange 和 queue 之间的虚拟连接,binding 中可以包含 routing key。Binding 信息被保存到 exchange 中的查询表中,用于 message 的分发依据

常用交换器

RabbitMQ常用的交换类型有direct、topic、fanout三种。

  • Direct Exchange 该类型的交换器将所有发送到该交换器的消息被转发到RoutingKey指定的队列中,也就是说路由到BindingKey和RoutingKey完全匹配的队列中。
    Direct Exchange图
  • Topoc Exchange 该类型的交换器将所有发送到Topic Exchange的消息被转发到所有RoutingKey中指定的Topic的队列上面。
    Exchange将RoutingKey和某Topic进行模糊匹配。
    Topic Exchange图
  • Fanout Exchange 该类型不处理路由键,会把所有发送到交换器的消息路由到所有绑定的队列中。有点是转发消息最快,性能最好。
    Fanout Exchange图
  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值