-----------------------------------------------------------------------------------------------------------
【爱测试·爱分享】
更多内容可关注公众号：测试专享
专注于性能、自动化、接口测试、中间件等技术，与您分享测试技术点滴，内容涵盖：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等热门测试技术，让您在实战中提升自我。在手机上阅读所有文章，随时随地都能学习。
----------------------------------------------------------------------------
