mq测试方法,mq异常处理

　　00-1010前言一、RocketMQ消息模式集群消费模式广播消费模式二、推拉模式的优缺点推送模式三、刷盘策略同步刷盘异步刷盘四、MQ异常测试MQ消息体消息重复发送消息到达顺序不一致消息发送失败重试连接生产者消息丢失消息争用MQ比落库快

　　00-1010上一篇文章总结了redis的异常测试。今天再来一个MQ相关的。

　　和redis一样，也是当前系统服务中不可或缺的中间件，通常用于流量削峰、应用解耦、异步处理等。

　　之前已经有了MQ快速入门的介绍，分类，组成，优缺点，测试要点。有兴趣可以跳过去看看。

　　日常系统主要使用RocketMQ，这是阿里系下的一个分布式、队列模型的开源消息中间件。是阿里参考kafka设计思想，用java实现的一套MQ，并做了自己的改进。广泛应用于订单、交易、充值、流计算、消息推送、日志流处理等场景。

　　下面简单介绍一些知识点。

　　在

前言

RocketMQ的默认消息模式是集群模式。当有多个消费者时，通过一定的负载平衡策略将消息分发给多个消费者。

　　例如，如果现在有三个消费者，那么传递的消息将仅由消费者1、消费者2和消费者3中的一个消费。

　　在RockeMQ中，通过ConsumeGroup的机制，实现了自然的消息负载均衡，添加机器实现横向扩展非常方便。

　　00-1010在这种模式下，消息将被分发给每一个消费者。当一条消息被传递时，它将被消费者1、消费者2和消费者3消费一次。就像发个朋友圈，你所有的朋友都能看到。

　　目前使用较多的是集群模式，也可以模拟广播消费。

　　00-1010对于任何消息中间件，消费者客户端通常有两种方式从消息中间件获取消息并使用它们。

　　00-1010消费者客户端主动从消息中间件(MQ消息服务器代理)提取消息。

　　适用场景：当生产者的生产报文数据量大，消费者的处理复杂，消费力相对较低。

　　优点：消费者可以根据自己的消费能力进行消费，生产者不需要和消费者保持对话。

　　缺点：拉消息的间隔没有设置好。间隔太短，对服务器请求压力太大。如果间隔太长，部分数据会延迟，实时性能相对较低。

　　优化方案：

　　长轮询消耗需要服务器和客户端的配合。

　　即客户端发送消息请求，服务器接受请求。如果服务器队列中没有新消息，服务器不会立即返回，而是将请求保留一段时间(通过设置超时)。在此期间，它轮询服务器队列以查看是否有新消息。如果有任何新消息，它将使用现有的连接将消息返回给消费者。如果在这段时间内没有新消息进入队列，它将返回null。

　　长轮询的缺点：在持有消费者请求期间会占用系统资源，因此长轮询适用于客户端连接数可控的业务场景。

　　00:00-10:10，消息服务器主动向消费者推送消息，尽快将消息发送给消费者进行消费。

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

　　优点：生产者主动推送给消费者，时效性高。

　　缺点：当消费者的消费能力远远低于生产者的生产能力时，一旦生产者向消费者推送大量消息，就会导致消费者消息堆积，处理缓慢，甚至服务崩溃。

　　此外，生产者需要与每个消费者保持对话。

　　优化方案：不使用http长连接来保持会话，而是采用套接字监控。

一、RocketMQ 消息模式

RocketMQ的内存读写是基于JDK NIO的内存映射机制。消息存储时，先追加到内存中，然后根据不同的刷机策略在不同的时间进行刷机。

　　00-1010同步刷是指数据到达内存后，必须刷到commitlog日志才算成功，然后返回生产者数据已经发送成功。

　　00-1010表示数据到达内存后，返回生产者说数据已经发送成功，然后写入commitlog日志。

　　什么是commitlog？

　　Commitlog是存储所有元信息，包括消息体，类似于Mysql和Oracle R。

　　edolog。所以只要有 CommitLog 在，Consume Queue即使数据丢失，仍然可以恢复出来。

　　而 consumequeue，就是用来记录数据的位置，以便 Consumer 快速通过 consumequeue 找到 commitlog 中的数据。

四、MQ 异常测试

MQ消息体

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

消息重复发送

消息重复发送，只消费一条，一般根据消息内容中唯一标识来去重。

消息到达顺序不一致

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

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

消息发送失败重试

Producer端重试

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

　　Consumer端重试

　　默认16次，重试时间间隔会越来越长，如果失败的多，容易堆积。这里的重试次数可自定义设置。

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

接线上生产者

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

消息丢失

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

消息争用

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

　　比如开发为了省事，预发和线上同一个topic，消费组的group也一样，上线后，可能存在有效消息被预发消费组消费了。

MQ比落库快

比如某接口A，新增一条数据后会同步更新DB和发送MQ给服务B，服务B收到消息后查询DB这条数据。曾经发现了收到消息却查不到数据的情况，因为数据库更新速度没有MQ快，后来改成异步了。

　　以上就是盘点MQ中的异常测试的详细内容，更多关于MQ异常测试的资料请关注盛行IT其它相关文章！

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。