1. MQ的基本概念
1. MQ概述
MQ全称Message Queue(消息队列),是在消息的传输过程中保存消息的容器。多用于分布式系统之间进行通信。
2. MQ的优势
2.1 应用解耦
引入MQ前系统弊端
- 系统的耦合性越高,容错性就越低
以上是一个传统系统的架构图,服务之间高度耦合,若库存系统崩溃,则订单系统对库存系统的请求不通,间接导致订单系统与别的系统之间交互失败,整个系统奔溃。 - 可维护性越低
如果需要增加新的系统,则订单系统的代码也需要修改,拓展性不高。
引入MQ后系统后
- 应用间解耦,提升容错性和可维护性
库存等系统都与MQ进行交互,不与订单系统直接交互,应用间解耦。
2.2 异步提速
- 提升用户体验和系统吞吐量(单位时间内处理请求的数目)
备注:系统的设计是基于同步场景下考虑的。
引入MQ前一个下单操作耗时:
20+100+100+100=320ms
用户点击下单按钮后,需要等待320ms才能得到下单响应,耗时较多,体验较差。
引入MQ系统后一个下单操作耗时:
用户点击下单按钮后,只需等待20+5=25ms,就能得到下单响应。
因为订单系统只需要与DB以及MQ系统交互即可。而此时可以开启三个MQ(MQ内部也是队列,请求也是按顺序处理)来处理三个请求,达到异步提速。
2.3 削峰填谷
- 提升系统稳定性
假如高峰期,每秒并发请求数量突暴增到 5000条。系统每秒处理1000请求,如果每秒请求到 5k 的话,可能就直接系统给打死了,导致系统崩溃,用户也就没法再使用系统了。
这个时候如果使用MQ,每秒中由5k个请求写入MQ中,系统每一秒处理1000个请求,A系统慢慢的拉去请求,这个时候,系统就能够在自己的承受范围之内,哪怕是高峰期也不会挂掉。使用了 MQ 之后,限制消费消息的速度为1000,这样一来,高峰期产生的数据势必会被积压在 MQ 中,高峰就被“削”掉了,MQ承受请求能力较强,但是因为消息积压,在高峰期过后的一段时间内,消费消息的速度还是会维持在1000,直到消费完积压的消息,这就叫做“填谷”。
3 MQ的劣势
3.1 系统可用性降低
系统引入的外部依赖越多,系统稳定性越差。一旦MQ宕机,就会对业务造成影响。
- 那么问题来了,如何保证MQ的高可用?
3.2 系统复杂度提高
MQ的加入大大增加了系统的复杂度,以前系统间是同步的远程调用,现在是通过MQ进行异步调用。
- 那么问题来了,如何保证消息不被丢失等情况?
4 常见的MQ产品
RabbitMQ | ActiveMQ | RocketMQ | Kafka | |
---|---|---|---|---|
公司/社区 | Rabbit | Apache | 阿里 | Apache |
开发语言 | Erlang | Java | Java | Scala&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协议简直就是一模一样。
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完全匹配的队列中。
- Topoc Exchange 该类型的交换器将所有发送到Topic Exchange的消息被转发到所有RoutingKey中指定的Topic的队列上面。
Exchange将RoutingKey和某Topic进行模糊匹配。
- Fanout Exchange 该类型不处理路由键,会把所有发送到交换器的消息路由到所有绑定的队列中。有点是转发消息最快,性能最好。