建设一个网站可以采用哪几种方案,网站关联词搜索怎么做,wordpress seo tdk,全球十大建筑设计公司RocketMQ如何测试MQ简介RocketMQRocketMQ测试点MQ简介
MQ#xff1a;Message Queue#xff0c;即消息队列#xff0c;是一种应用程序之间的消息通信#xff0c;简单理解就是A服务不断的往队列里发布信息#xff0c;另一服务B从队列中读取消息并执行处理#xff0c;消息发…
RocketMQ如何测试MQ简介RocketMQRocketMQ测试点MQ简介
MQMessage Queue即消息队列是一种应用程序之间的消息通信简单理解就是A服务不断的往队列里发布信息另一服务B从队列中读取消息并执行处理消息发布者不需要关心是谁消费了消息消息消费者不需要关心发布消息的是谁互不干扰。
消息队列主要作用和优势 异步和解耦 以电商订单处理为例用户提交一个订单如果订单系统以同步方式调用 支付、库存等服务。服务之间就会有很高耦合性容错性会降低。一旦支付或库存服务宕机那么就会导致订单提交失败整个交易的异常。从而影响用户的体验。 如果中间加入了消息中间件不管是支付还是库存等服务通过异步的方式进行调用的如果其中一个服务宕机了提交订单仍收到正常响应不会影响用户下单的使用同时不用等待其它服务的结果提高了处理效率。然后等服务恢复后可以从消息队列获取消息继续进行订单的后续处理。 流量削峰 流量削峰也叫削峰填谷例如一些电商秒杀或购物节活动都会使用到消息中间件。 如果在不使用消息中间件活动期间每秒是很高的并发如果A服务需要要将数据写入到MySQL中由于MySQL本身服务的上限会有大量的请求堆积在A服务去处理结果会导致A服务的的崩溃。 这时将用户的请求写入存储到MQ中因为消息中间件本身是对数据量处理比较高的一个系统所以对于高并发的请求消息中间件仍可以处理然后A服务作为消息中间件的一个消费者以固定的速度从MQ中拉取消息处理并完成相关业务操作进而确保我们A服务的稳定性。 数据分发 可扩展性等
常见的MQ主要有RocketMQ、ActiveMQ、RabbitMQ、Kafka各有优势。其中RocketMQ作为阿里开源的一款高性能、高吞吐量的分布式消息中间件。历经过很多高并发数据处理的磨练无数业务场景的应用足以证明它的优秀。
RocketMQ
简单来说RocketMQ就是一个分布式发布-订阅消息中间件底层基于队列模型来实现消息收发功能。
RocketMQ结构包含4个模块NameserverBrokerProducerConsumer。
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 是顺序的但是当并行消费时还是会有顺序问题 但是串行消费也同时引入了两个问题引入锁来实现串行、前一个消费阻塞时后面都会被阻塞
