MQ简介

MQ：Message Queue，即消息队列，是一种应用程序之间的消息通信，简单理解就是A服务不断的往队列里发布信息，另一服务B从队列中读取消息并执行处理，消息发布者不需要关心是谁消费了消息，消息消费者不需要关心发布消息的是谁，互不干扰。

消息队列主要作用和优势：

• 异步和解耦
  以电商订单处理为例，用户提交一个订单，如果订单系统以同步方式调用 支付、库存等服务。服务之间就会有很高耦合性，容错性会降低。一旦支付或库存服务宕机，那么就会导致订单提交失败，整个交易的异常。从而影响用户的体验。
  如果中间加入了消息中间件，不管是支付还是库存等服务，通过异步的方式进行调用的，如果其中一个服务宕机了，提交订单仍收到正常响应，不会影响用户下单的使用，同时不用等待其它服务的结果，提高了处理效率。然后等服务恢复后可以从消息队列获取消息，继续进行订单的后续处理。

• 流量削峰
  流量削峰也叫削峰填谷，例如一些电商秒杀或购物节活动，都会使用到消息中间件。
  如果在不使用消息中间件，活动期间每秒是很高的并发，如果A服务需要要将数据写入到MySQL中，由于MySQL本身服务的上限，会有大量的请求堆积在A服务去处理，结果会导致A服务的的崩溃。
  这时将用户的请求写入存储到MQ中，因为消息中间件本身是对数据量处理比较高的一个系统，所以对于高并发的请求，消息中间件仍可以处理，然后A服务作为消息中间件的一个消费者，以固定的速度从MQ中拉取消息，处理并完成相关业务操作，进而确保我们A服务的稳定性。

• 数据分发

• 可扩展性等

常见的MQ主要有：RocketMQ、ActiveMQ、RabbitMQ、Kafka，各有优势。其中RocketMQ作为阿里开源的一款高性能、高吞吐量的分布式消息中间件。历经过很多高并发数据处理的磨练，无数业务场景的应用，足以证明它的优秀。

RocketMQ

简单来说，RocketMQ就是一个分布式发布-订阅消息中间件，底层基于队列模型来实现消息收发功能。

RocketMQ结构包含4个模块：Nameserver，Broker，Producer，Consumer。

Nameserver 名称服务：名称服务是一个Topic路由注册中心，充当路由消息的提供者。生产者或消费者能够通过名字服务查找各Topic相应的Broker IP列表，存储当前集群所有Brokers信息、Topic跟Broker的对应关系。

Broker 代理服务器：集群最核心模块，主要负责Topic消息存储、消费者的消费位点管理（消费进度）。Consumer 从这里取得消息。Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，Message Queue 用于存储消息的物理地址。消息相关的元数据，包括用户组、消费进度偏移量、队列信息等

Producer 消息生产者：由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。每个生产者都有一个ID(编号)，多个生产者实例可以共用同一个ID。同一个ID下所有实例组成一个生产者集群。

Consumer 消息消费者：负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序，执行完成后会发送一个消息给Broker进行确认，这个就是ACK确认。提供了两种消费形式：PullConsumer(拉取式消费)、PushConsumer(推动式消费)。每个订阅者也有一个ID(编号)，多个消费者实例可以共用同一个ID。同一个ID下所有实例组成一个消费者集群。

RocketMQ测试点

1、消息正向验证。验证消费主流程是正常的，消息发送和消费都正常情况下，消息生成和消费及流程处理无误。可通过RocketMQ控制台查找对应的Topic，找到对应的Message ID的数据，核对数据内容

2、逆向用例与异常值处理
对于Produce和Consumer两端的异常消息处理，如消息某个参数为空，为异常的情况，在Produce发送错误信息后，消费端是否能够有效处理错误问题。需要对日志和数据库等方面进行查看。

3、消息丢失时的处理情况，（模拟网络等问题）
如因为网络原因导致的消息丢失，是否有补发，通常情况下Produce会设置补发。如果是落库到OS存储、硬盘存储过程中的问题，如何保证消费正常？

4、消息避免重复发送
由于RocketMQ天生就有消息重复发送的机制，所以当产生消息重新发送时，如何对此问题进行处理？通常情况下要对消费端的服务做幂等处理，保证消息不被重复消费。

5、性能相关问题，消费积压
主要是性能测试，可以通过RocketMQ的控制台，查看对应消息消费的TPS，来保证消费的及时性，看是否有消息产生阻塞消费，导致消费TPS波动或骤降等问题。

6、消费的先后顺序以及消费阻塞问题
与定时消息同原理，生产者生产消息时指定特定的 MessageQueue ，消费者消费消息时，消费特定的 MessageQueue，当然如果只有单个MessageQueue，则不会有消费顺序的问题。
同一个 MessageQueue 保证里面的消息是顺序消费的前提是：消费者是串行的消费该 MessageQueue，因为就算 MessageQueue 是顺序的，但是当并行消费时，还是会有顺序问题
但是串行消费也同时引入了两个问题：引入锁来实现串行、前一个消费阻塞时后面都会被阻塞