作为测试你应该知道的MQ知识(一)

【爱测试·爱分享】

更多内容可关注公众号：测试专享

       专注于性能、自动化、接口测试、中间件等技术，与您分享测试技术点滴，内容涵盖：Jmeter、PTS、Python、Selenium、小程序自动化、Linux等热门测试技术，让您在实战中提升自我。在手机上阅读所有文章，随时随地都能学习。

       笔者收到几位小伙伴的私信，作为测试工程师，需要学习消息队列MQ吗？从测试职业发展，保持市场竞争力的角度来看，掌握一些底层技术，深耕个人技术栈的深度，对测试工作是有重要的作用的。接下来我带你学会MQ，提升你的技术栈，让开发测试都对你刮目相看~

一、消息队列有什么作用？

   在分布式场景下，消息队列MQ基本上是标配，在很多场景下都会用到，MQ主要有三大角色（生产者、消息服务、消费者），大致的过程是这样的：

在这个过程中，发送和接收是异步的，也就是发送无需等待，而且发送者和接收者的生命周期也没有必然的关系；以下以电商中最常见的秒杀场景为例分析消息队列的作用。

1、异步处理

① 不使用消息队列下单步骤：

以上，从用户下单需要经历5个流程才能返回结果给用户，用户需要等待结果的返回。

② 使用消息队列后下单步骤：

以上，从用户下单只经历2个流程就可以返回结果给用户，生成订单、短信通知、更新统计数据都是异步通过MQ消费的，无需等待这3个流程的结果，缩短了响应时间。

2、服务解耦

① 不使用消息队列下单：

以上，一个下单流程经历了4个系统。当任何一个系统出现问题无法访问时, 订单也会失败。订单系统与其他系统耦合。

② 使用消息队列后下单：

【订单系统】：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。

【其他系统】：订阅下单的消息，采用pull或push的方式，获取下单信息，库存系统根据下单信息，进行库存操作。
此时，其他系统出问题，不会影响到订单系统。这就是将原来耦合的两个系统实现了应用解耦。

3、流量削峰

前面说的秒杀活动异步处理仅仅只是提升响应速度，但是面对秒杀场景也需要做好流量控制，避免流量过大将秒杀系统压垮。因此可以利用消息队列隔离网关和后端服务，以达到流量控制和保护后端服务的目的。

        以上，当短时间内大量的秒杀请求到达网关时，不会直接冲击到后端的秒杀服务，而是先堆积在消息队列中，后端服务按照自己的最大处理能力，从消息队列中消费请求进行处理。这样，能根据下游的处理能力自动调节流量，达到“削峰填谷”的作用。

二、常见的消息队列 

消息队列有很多成熟的产品，每一个产品都有自己的优势和劣势，常见的MQ产品有：

（1）RocketMQ：阿里下的开源产品，用在电商场景比较多，Java开发的，低延时，非常适合在线业务，活跃的中文社区。

（2）ActiveMQ：老牌的开源消息队列，目前社区不活跃，功能及性能方面比较欠缺，目前在一些遗留的系统比较常用。

（3）RabbitMQ：Erlang开发的，对消息堆积的支持不好，会导致性能急剧下降。

（4）Kafka：Scala开发的，开始用于处理海量日志，大多用于大数据和流计算领域，与周边生态系统的兼容性最好。

        在后面文章中，笔者会以RocketMQ作为例子进行分享，掌握后看其他就很容易理解~

三、MQ的核心概念

1、Producer 

生产者。负责生产消息，RocketMQ提供多种发送方式：同步发送、异步发送、顺序发送、单向发送。

2、Comsumer 

消费者。负责消费消息，从用户应用的角度而言提供了两种消费形式：拉取式消费(pull)、推动式消费(push)。

3、Publish 

发布。指的是发布消息到MQ的，如下单的订单服务，此时订单服务为发布者。

4、Subscribe 

订阅。指例如发送短信、发送微信消息的服务订阅MQ，此时订阅的服务为消费者。

5、Producer Group 

同一类Producer的集合。这类Producer发送同一类消息且发送逻辑一致。如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。

6、Consumer Group 

同一类Consumer的集合。这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。要注意的是，消费者组的消费者实例必须订阅完全相同的Topic。RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费（Broadcasting）。

7、Topic 

主题名称。生产者发布消息到MQ，需要指定一个Topic，消费者也需要指定具体是监听哪个Topic的消息，当该topic有消息就会进行消费。

8、Name Server  

名称服务器。用于保存 Broker 相关元信息，为Producer 和 Consumer 提供查找 Broker的信息。Producer发送消息时，需先请求Name Server获取Topic的路由信息，再根据Topic路由信息路由到Broker；同样的，Consumer消费消息时，也是先请求Name Server获取Topic路由信息，再根据Topic路由信息路由到Broker。

9、Broker 

消息存储。Broker是RocketMQ的核心，提供了消息的接收、存储、拉取等功能。每个broker与Name Server集群中的所有节点建立长连接，注册Topic等信息到所有Name Server。一般都需要保证Broker的高可用，所以会配置Broker Slave，当Master挂掉之后，Consumer可以消费Slave；Broker分为Master和Slave，一个Master可以对应多个Slave，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave；

【Broker保存以下内容】：

• • 所有的消息；

  • 所有consumer的消费偏移量；

  • 所有consumer的订阅关系；

  • 所有的Topic信息；

  • 延迟队列的消费进度；

10、Queue 

队列。是消息队列RocketMQ中消息存储和传输的实际容器，也是消息的最小存储单元。消息队列RocketMQ的所有主题都是由多个队列组成，以此实现队列数量的水平拆分和队列内部的流式存储。队列通过QueueId来做唯一标识和区分。

11、Message 

消息体。根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输。

【爱测试·爱分享】

更多内容可关注公众号：测试专享

专注于性能、自动化、接口测试、中间件等技术，与您分享测试技术点滴，内容涵盖：Jmeter、PTS、Python、Selenium、小程序自动化、Linux等热门测试技术，让您在实战中提升自我。在手机上阅读所有文章，随时随地都能学习。