MQ的分类组成优缺点测试点入门教程

一、什么是 MQ

MQ全称是 Message Queue,本质上是个队列,原则还是先进先出,只不过队列里存放的元素是一条条 Message 。

工作中常见被用于上下游传递消息,实现一种跨进程的通信。这样一来,要发送消息的上游服务只依赖 MQ 即可,与下游服务解耦,我觉得可以理解成中介。

二、MQ 的作用

1. 流量削峰

举个栗子,这里有一个订单系统处理用户下单的业务逻辑。这个系统的服务能力假设为 1S 处理1万次订单,那么正常来说,不超过1万次对它来说都没问题。但是,如果到了用户下单的高峰期,这时候的单量可能就要超过系统服务能力。

这时候可以加入 MQ,把1s内下的订单进行排队,分散在一段时间内处理,虽然说会导致有些用户会在几秒之后才能收到下单成功,但是比起不能下单还是要好很多了。

2. 应用解耦

现在有个电商应用,里面包含了好多个子系统:订单系统、库存系统、物流系统、支付系统等。

先看下耦合在一起的情况,当用户创建订单后,如果后面任何一个子系统出现了故障,都会造成用户的下单操作异常。

MQ的分类组成优缺点测试点入门教程_第1张图片

现在加上 MQ 后,订单系统的工作完成后,接下来的事情就转交给MQ了。MQ 会分配消息给其他的3个系统,直到3个系统执行完成。如果存在其中有不能完成的系统,队列会监督它继续完成。比如物流系统坏了,但是订单系统不受影响,用户感觉不出来有异常,依旧可以看到成功下单的提示。当物流系统恢复正常以后,继续处理订单信息即可,从而提升了整个系统的可用性。

MQ的分类组成优缺点测试点入门教程_第2张图片

3. 异步处理

在生产中,有些服务间的调用是异步的。A 调用 B,但是 B 需要花费一段时间来处理。没有 MQ 的时候通常这样处理:

  • A 轮询的调用 B的查询,看看结果是不是处理好了。
  • A 提供一个callback 回调接口,B 执行好了调用这个api接口通知 A。

加入 MQ 后,这时 A 再调用 B 后,只需要监听 B 处理完成的消息即可。当 B 处理完成后,会发送一条消息给 MQ,然后 MQ 会把消息转发给 A。所以,现在 A 既不用轮询 B,也不用提供回调api

MQ的分类组成优缺点测试点入门教程_第3张图片

三、MQ 的缺点

MQ 这么好用,难道就没有缺点吗? 有。

  • 首先,在系统里加入了一个中间件服务,无疑是会增加了系统复杂度。
  • 如果 MQ 宕机了,不能用了,那么后面的流程也没法处理了。
  • 存在一致性问题。比如订单系统创建好了订单,发给下游的消息没发出去,那么就产生了脏数据。再比如,先发送了订单的消息,再去创建订单,如果创建失败了,消息却发送成功了,此时下游以为已经创建好了订单。
  • 其他问题,比如消息丢失,重复发送相同消息,消息被其他系统消费,消息大量积压等等,都需要我们有对应方案解决。

对于一致性问题,在 testerhome 有看到过一位大佬分享的经验:
首先,消费者在消费成功后通过同步请求或者另一条 mq 队列,反馈给生产者,生产者更新自己内部这条消息的状态为已处理。

同时生产者内置一个定时任务,查看内部所有待处理消息是否超时,如果超时,进行自动补偿。补偿大概步骤是:

  • 发起 http 同步查询给消费者,确认消费者是否有消费
  • 若消费者反馈已消费,直接更新生产者自身内部消息状态
  • 若消费者反馈未收到,则进行预警,人工介入处理(一般不会直接重发,因为重发有可能引发更严重的问题,如加剧 mq 消息堆积的情况)

四、常见 MQ 分类

1. ActiveMQ

Apache下的一个子项目。使用Java完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,少量代码就可以高效地实现高级应用场景。

优点:

  • 单机吞吐量: 万级。
  • 时效性: ms级。
  • 可用性:高。
  • 消息可靠性:较低概率出现丢失数据。

缺点
官方社区现在对于 ActiveMQ 5.x的版本维护越来越少,高吞吐量场景较少使用。

2. Kafka

Apache下的一个子项目,使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统。尤其在大数据上是个杀手锏,吞吐量在百万级,在数据采集、传输、存储的过程中发挥举足轻重的作用。

优点

  • 单机吞吐量: 百万级。
  • 时效性: 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 中取出并且消费消息。

MQ的分类组成优缺点测试点入门教程_第4张图片

  • 消息被消费以后,queue中不再存储,所以消息消费者不可能消费到已经被消费的消息。
  • Queue支持存在多个消费者,但是对一个消息而言,只会有一个消费者可以消费。

2)发布订阅模式

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

MQ的分类组成优缺点测试点入门教程_第5张图片

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

六、MQ 测试需要的关注点

1. 对于生产者

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

2. 对于消费者

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

3. 对于队列

  • 宕机恢复后,消息是否丢失
  • 宕机预案,多久能恢复,如果无法恢复的预案
  • 不同的消息格式,是否能正常识别及转发

具体关注点,其实还要看具体业务来,这些都可以做些了解,如果有涉及到与MQ交互的,可以从多方面去考虑,增加测试覆盖。

最后本文参考文章

https://www.jb51.net/article/249620.htm

https://www.jb51.net/article/219482.htm

以上就是MQ的分类组成优缺点测试点入门教程的详细内容,更多关于MQ分类组成测试点的资料请关注脚本之家其它相关文章!

你可能感兴趣的