mq测试方法,常用mq比较

　　00-1010一、什么是MQ二。MQ 1的作用。流量削峰2。应用解耦3。异步处理。MQ IV的缺点。常见MQ分类1。ActiveMQ 2。卡夫卡3。火箭MQ 4。兔子MQ v . mq1的组成。角色2。MQ消息模式6。MQ测试需要关注的问题1。对于制作人2。对于消费者来说。

一、什么是 MQ

　　00-1010以一个栗子为例。这里有一个订单系统来处理用户下订单的业务逻辑。该系统的服务能力假设为在1S内处理10，000个订单，因此通常不超过10，000个订单就可以了。但如果是用户下单的高峰时间，此时的单量可能会超过系统的服务能力。

　　这时候可以加入MQ，对1s内下单的订单进行排队，并在一段时间内进行处理。虽然会导致部分用户在几秒钟后收到成功订单，但总比不能下单好很多。

　　00-1010现在有一个电子商务应用，包含很多子系统：订单系统、库存系统、物流系统、支付系统等。

　　我们先来看耦合情况。当用户创建订单时，如果以下任一子系统出现故障，用户的下单操作将会异常。

　　现在有了MQ的加入，订单系统的工作完成后，接下来的事情就转移到MQ了。MQ将消息分发到其他三个系统，直到这三个系统的执行完成。如果有系统无法完成，队列会监督其继续完成。比如物流系统坏了，但订单系统不受影响。用户感觉不到任何异常，仍然可以看到订购成功的提示。当物流系统恢复正常后，可以继续处理订单信息，从而提高整个系统的可用性。

　　00-1010在生产中，服务之间的一些调用是异步的。a调用B，但是B需要一段时间来处理。没有MQ时，通常是这样处理的：

　　轮询A对B的查询的调用，看结果是否被处理。A提供一个回调接口，B在调用完这个api接口后通知A。加入MQ后，当A再次调用B时，只需要监听B已经处理完的消息。B处理完了，会给MQ发消息，然后MQ再把消息转发给A，所以现在A既不轮询B，也不提供回调api。

二、MQ 的作用

MQ这么好用，难道没有缺点吗？是的。

　　首先，在系统中增加一个中间件服务，无疑会增加系统的复杂度。如果MQ宕机，无法使用，那么后面的流程就无法处理。有一个一致性问题。例如，如果订单系统创建了一个订单，而向下游发送的消息没有发送，那么就会产生脏数据。例如，首先发送订单的消息，然后创建订单。如果创建失败，则消息发送成功。此时下游认为订单已经创建。其他问题，如消息丢失、同一消息重复发送、消息被其他系统消耗、消息大量积压等。都需要我们有相应的解决方案。关于一致性问题，我在testerhome看到过一个老大哥分享的经验：首先，消费成功后，消费者通过一个同步请求或者另一个mq队列反馈给生产者，生产者在自身内部更新这个消息的状态为已处理。

　　同时，生产者内置了一个调度任务，检查所有要处理的内部消息是否超时，如果超时，进行自动补偿。大致的补偿步骤如下：

　　向消费者发起http同步查询，确认消费者是否消费过。如果消费者的反馈已经消费，直接更新生产者的内部消息状态。如果没有收到消费者的反馈，提前预警，人工处理(一般不会直接重发，因为重发可能会造成更严重的问题，比如加重mq消息的堆积)

1. 流量削峰

　　00-1010 Apache下的子项目。随着Java完全支持JMS1.1和J2EE 1.4规范的JMS提供者的实现，少量代码就可以高效地实现高级应用场景。

　　优势：

　　单机吞吐量：10000。时效性：ms级别。可用性：高。可靠性：数据丢失概率低。缺点官方社区现在维护的ActiveMQ 5.x版本越来越少，使用的高通量场景也越来越少。

　　00-1010 Apache下的子项目，Apache是scala实现的高性能分布式发布/订阅消息队列系统。尤其是在

　　大数据上是个杀手锏，吞吐量在百万级，在数据采集、传输、存储的过程中发挥举足轻重的作用。

　　优点

　　单机吞吐量：百万级。时效性： ms级。可用性：非常高。消息可靠性：可配置 0 丢失。分布式：一个数据有多个副本，少数机器宕机也不会丢失数据。缺点

　　单机超过64个队列/分区，CPU会明显变高，队列越多越高，发送消息响应时间变长。消费失败不支持重试。Kafka主要特点是基于PULL的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。

3. RocketMQ

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

　　优点

　　单机吞吐量：十万级。时效性： ms级。可用性：非常高。消息可靠性：可配置 0 丢失。分布式：支持。扩展性好，支持10亿级别的消息堆积。源码是java，有利于定制。缺点

　　支持的语言不多，主要是java，C++还不成熟。社区活跃也一般，没有在 MQ 核心中实现 JMS 等接口，有些系统需要迁移则要修改大量代码。

　　RocketMQ 天生为了金融互联网而生，对于可靠性要求很高的场景，比如电商里的扣款，它更值得信赖。

4. RabbitMQ

使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。

　　优点

　　单机吞吐量：万级。时效性：μs级。可用性：高。消息可靠性：基本不丢失。支持多语言。社区活跃度高，更新频率高缺点

　　商业版需要付费，学习成本较高。

　　RabbitMQ 性能好，时效性强，管理界面也很友好。如果数据量没那么大，中心型业务可以优先选择功能完备的 RabbitMQ。

五、MQ 的组成

1. 角色

Broker：消息服务器，提供消息核心服务Producer：消息生产者，业务的发起方，负责生产消息传输给broker。Consumer：消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理。Topic：主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的广播。Queue：队列，点对点模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收。Message：消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输。

2. MQ 消息模式

1)点对点模式

　　使用 queue 作为通信载体，消息生产者生产消息发送到 queue 中，然后消息消费者从 queue 中取出并且消费消息。

　　消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。2)发布订阅模式

　　使用topic作为通信载体，1个生产者可以对应多个消费者。消息生产者(发布)将消息发布到topic中，同时有多个消息消费者(订阅)消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。

　　就像你发了个朋友圈，你的朋友们都可以看到。

六、MQ 测试需要的关注点

1. 对于生产者

生成的数据格式是否跟定义的一致数据是否有成功推送到队列里数据是否有成功推动到对应的 topic推送失败时如何处理重复推送同一条数据，如何处理不同顺序推送消息，注意队列优先级推消息耗时，队列容量达到上限，无法推送后如何处理

2. 对于消费者

消费的消息是否来自订阅的 topic消息被消费了，是否有清除生产者推送过快，消费速度过慢（堵塞），会如何无法消费没订阅的 topic 消息生产者推送消息后，消费者接受到的消息内容跟生产者推的一致如何处理重复消息，比如幂等处理超时消息处理失败消费消息的优先级是否跟推的一致消费消息耗时消费者宕机，消息堆积，无人处理，会如何处理是否能正常消费消息

3. 对于队列

宕机恢复后，消息是否丢失宕机预案，多久能恢复，如果无法恢复的预案不同的消息格式，是否能正常识别及转发具体关注点，其实还要看具体业务来，这些都可以做些了解，如果有涉及到与MQ交互的，可以从多方面去考虑，增加测试覆盖。

　　最后本文参考文章

　　https:///article/249620.htm

　　https:///article/219482.htm

　　以上就是MQ的分类组成优缺点测试点入门教程的详细内容，更多关于MQ分类组成测试点的资料请关注盛行IT其它相关文章！

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