MQ异常测试

1、MQ消息体中某些必填参数为NULL，或者全部必填为NULL，字段类型、长度是否不符合约定

2、MQ消息体中参数位置错误

3、消息重复发送，只消费一条 —幂等性

一般根据消息内容中唯一标识来去重

4、消息到达顺序不一致，导致业务异常

比如业务是有先后顺序的

案例1：订单下单后再取消，如果先收到取消的消息，再收到下单消息，就会有问题

案例2：一条政策新增后马上删除，政策同步时，政策删除的消息先到达，新增的消息后到，就会导致最小价该条政策没删除，只能等全量同步的时候再删除

5、消息发送失败，重试次数

1）Producer端重试

比如网络抖动导致生产者发送消息到MQ失败，可以手动设置发送失败重试的次数

2）Consumer端重试

默认16次，重试时间间隔会越来越长，如果失败的多，容易堆积

重试次数可自定义设置

消费者端失败分2种

A、Exception

如反序列化失败

B、timeout

只有消息推送失败才需要重推，需要注意开发不要把其他失败的情况也进行重试

如收到消息，但解析消息时，序列化失败，这种算消息发送成功的

还比如政策同步时，消费者收到消息，但特殊情况消费异常，也去做了重试

6、机器重启时间段的消息，消费者能否消费到

7、push的类型，需要测试当有生产者生成消息时，消费者是否能及时得到信息并消费

8、Pull类型的消费者，需要测试拉取的时间间隔，间隔一段时间再有消息延迟性

9、消费时消费节点测试

接线上已有的生产者，需要注意，必须设置消费开始时间，不然上线时会大批量消息过来会造成堆积，造成故障

10、消息丢失，业务是否兼容，是否有补偿或者监控机制

比如政策同步消息丢失，还有全量航线同步进行补偿；

供应商退票先发消息给供应商，退订这边会监控，临近跨退规节点，会去调供应商接口检查是否已推送供应商退票，没有退票的会自动再推一遍

11、消费模式注意，消息争用

如果是集群模式，同一topic下新增新的消费组，没有申请新的group，导致一条消息投递过来，多个消费组争抢

案例：有时候开发为了省事，预发和线上同一个topic，消费组的group也一样，上线后，可能有效消息就被预发消费组消费了

知识点：

一、RocketMQ消息模式

1、集群模式

一条消息投递过来，只会被consumer 1、consumer 2、consumer 3中的一个消费

2、广播模式

当 consumer 使用广播消费时，一条消息投递过来，会被 consumer 1、consumer 2、consumer 3都消费一次

目前我们用的比较多的是集群模式，集群模式可以模拟广播消费

如果业务上确实需要使用广播消费，那么我们可以通过创建多个 consumer 实例，每个 consumer 实例属于不同的 consumer group，但是它们都订阅同一个 topic。举个例子，我们创建 3 个 consumer 实例，consumer 1（属于consumer group 1）、consumer 2（属于 consumer group 2）、consumer 3（属于consumer group 3），它们都订阅了 topic A ，那么当 producer 发送一条消息到 topic A 上时，由于 3 个consumer 属于不同的 consumer group，所以 3 个consumer都能收到消息，也就达到了广播消费的效果了。 除此之外，每个 consumer 实例的消费逻辑可以一样也可以不一样，每个consumer group还可以根据需要增加 consumer 实例，比起广播消费来说更加灵活。

二、push 和 pull 的优缺点

push
优点：生产者主动推送给消费者，及时性很高
缺点：当消费者消费能力远低于生产者生产能力，那么一旦生产者推送大量消息到消费者时，就会导致消费者消息堆积，处理缓慢，甚至服务崩溃。（那么如何解决这个问题呢？需要mq提供流控制，也就是依据消费者消费能力做流控。比如rabbitmq设置Qos，限制消费数量。）生产者需要维护和每个消费者之间的会话。

优化方案：不采用 http 长连接的方法保持会话，采用 socket 监听。

适用场景：对于数据实时性要求高的场景

pull
优点：消费者可以依据自己的消费能力进行消费；生产者不需要维护和消费者之间的会话。

缺点：拉取消息的间隔不太好设置。间隔太短，对服务器请求压力过大。间隔时间过长，那么必然会造成一部分数据的延迟。
实时性相对较低。
优化方案：长轮询：消费者如果尝试拉取失败，不是直接 return，而是保持连接 wait，服务端如果有新的消息到来，返回最新消息。

适用场景：对于生产者生产消息数据比较大时，而消费端处理比较复杂，消费能力相对较低

三、刷盘方式

同步刷盘：在消息到达MQ后，RocketMQ需要将数据持久化，同步刷盘是指数据到达内存之后，必须刷到commitlog日志之后才算成功，然后返回producer数据已经发送成功。

异步刷盘：是指数据到达内存之后,返回producer说数据已经发送成功。，然后再写入commitlog日志。

commitlog：

commitlog就是来存储所有的元信息，包含消息体，类似于Mysql、Oracle的redolog,所以主要有CommitLog在，Consume Queue即使数据丢失，仍然可以恢复出来。

consumequeue：记录数据的位置,以便Consume快速通过consumequeue找到commitlog中的数据