MQ学习记录_mq每秒处理多少

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产品

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 该类型不处理路由键，会把所有发送到交换器的消息路由到所有绑定的队列中。有点是转发消息最快，性能最好。