MQ异步消息架构性能测试及瓶颈分析

一、简介

1.MQ的概念

MQ全称 Message Queue(消息队列),是在消息的传输过程中保存消息的容器。多用于分布式系统之间进行通信。是一种“先进先出”的数据结构。

2.MQ模型

生产者将消息发送给MQ。 MQ将消息推送给指定消费者,或者消费者去MQ拉特定的消息。 生产者和消费者又可以成为客户端,相对应MQ就是服务端

3.MQ与redis、传统数据库的区别

  • MQ消息队列服务:针对数据更改场景、功能比其他两者弱(发数据、取数据),是数据的临时中转地,主要用于新增、删除、或者及其少量的查询功能;处理速度比传统数据库快(操作更简单、没这么多约束。高性能的最重要原因:MQ操作是顺序读写为主,数据库是随机读取磁盘)

  • redis缓存技术:处理速度快,使用内存机制,主要针对查询场景

  • 传统的数据库:事务支持、持久存储、数据管理场景

4.常见的MQ

常见的MQ主要有activemq、rabbitmq、kafka、rocketmq

这里主要使用rocketmq,是阿里主导的,官网文档:https://rocketmq.apache.org/zh/docs/

二、MQ的作用

1.解耦

当 A 系统生产关键数据,发送数据给多个其他系统消费,此时 A 系统和其他系统产生了严重的耦合,如果将 A 系统产生的数据放到 MQ 当中,其他系统去 MQ 获取消费数据,此时各系统独立运行只与 MQ 交互,添加新系统消费 A 系统的数据也不需要去修改 A 系统的代码,达到了解耦的效果。

使用MQ后,将不同应用之间的调用解耦,提高系统容错性。如图,订单系统直接将订单消息发给MQ就结束了。 其他系统从MQ获取订单信息处理

2.异步提速

不同依赖服务之间的通信异步化,可以提高整个系统的吞吐量。如下图,不适用MQ时,单个请求总耗时20ms+3*300ms,使用MQ以后,20+5+300

3.削峰填谷

使用了 MQ 之后,限制消费消息的速度为1000,这样一来,高峰期产生的数据势必会被积压在 MQ 中,高峰就被“削”掉了,但是因为消息积压,在高峰期过后的一段时间内,消费消息的速度还是会维持在1000,直到消费完积压的消息,这就叫做“填谷”。

三、监控体系

下载rocketmq-console的jar包:https://download.csdn.net/download/qq_38571773/87388867

下载jar包后,启动命令:

java -jar -Dserver.port=9981 -Drocketmq.namesrv.addr=ip:端口号 rocketmq-console-ng-1.0.1.jar  # ip和端口号,为rocketmq部署时, 启动NameServer的服务器ip和端口号,默认端口是9876

启动后,可通过端口号进行访问:

主要查看主题top,主题为某一类的存放的统一标记,类似数据库里面的表。

消费者tab下,主要关注TPS和延迟,TPS为消费者程序中,每秒钟处理了多少的MQ消息;

延迟为堆积的MQ消息,等待消费者消费。

四、MQ架构测试注意事项

1.异步导致的延时性

不同的业务,对响应时间的关心程度不一样。所以需要根据具体业务情况,考虑是否接受采用异步导致的延迟时间

例如,点完外卖,评价送积分--->1)、先提交评价 ;2)、修改用户的积分

由于对增加积分的时间要求没这么高-->程序设计: 将 积分的相关操作设计为 异步操作

2.消息丢失

2.1消息模式类型:

  • sync同步模式:发送消息采用同步模式,这种方式只有在消息完全发送完成之后才返回结果,此方式存在需要同步等待发送结果的时间代价,具有内部重试机制

  • async同步模式:发送消息采用异步发送模式,消息发送后立刻返回,当消息完全完成发送后,会调用回调函数sendCallback来告知发送者本次发送是成功或者失败。异步模式通常用于响应时间敏感业务场景,即承受不了同步发送消息时等待返回的耗时代价;异步模式也在内部实现了重试机制,默认次数为2次-->针对网络问题调用失败

测试的时候要注意, 如果发送完毕之后,程序就挂掉了, 对于数据处理是否存在问题

异步发送消息代码之后,MQ不一定收到,而继续处理后面的代码 (理论上来说,上一个操作成功, 才能进行下一步操作),因为性能的考虑, 进行异步的MQ消息发送,可能会出现: MQ发送失败,而后面的操作成功了

往往程序设计, 要在接受 MQ 确认没问题的消息之后,进行一系列具体数据的处理;收到 MQ 处理失败的callback回调消息之后,要进行相对应重试设计

  • one-way生产者单向发送:采用one-way发送模式发送消息的时候,发送端发送完消息后会立即返回,不会等待来自broker的ack来告知本次消息发送是否完全完成发送。这种方式吞吐量很大,但是存在消息丢失的风险,所以其适用于不重要的消息发送,比如日志收集

2.2 MQ服务器的刷盘类型

收到数据 ,最终要持久化到 磁盘,存在两种方式落盘:

  • SYNC_FLUSH(同步刷新):MQ收到消息之后,写入磁盘

  • ASYNC_FLUSH(异步处理):MQ收到信息,保存在内存,定时批量写入磁盘

3.幂等性

幂等性包含两次语义:1)一个消息最少被消费一次; 2)一个消息只会被成功消息一次

因为消息发送的,有重试机制,可能导致 同一条消息 发送多遍。

所以消费者收到消息之后,要检查是否重复处理,使用业务上的唯一ID,如支付ID、交易号、订单号、消息编码等来进行检查

4.通过MQ做系统解耦

如果通过MQ进行系统拆分,本质来讲就是分布式架构,需要监控多个系统而不是只看 接口后台

五、瓶颈分析

1.资源问题

1.1. MQ -- 高并发 数据 存取, 网络要求不低公司的消息内容很大

1.2. CPU、内存、磁盘不够--可考虑集群架构

2.Rocket MQ 本身资源

MQ是用java 语言开发的, 堆内存优化查看官方手册:https://rocketmq.apache.org/zh/docs/bestPractice/19JVMOS

3.消息积压

当 生产者 发送大量数据到MQ, 消费者处理能力跟不上,就会导致积压,可以通过检查消费者程序的 处理逻辑 或者 消费者程序所在的服务器 资源是否够用

六、调优建议

所有MQ的调优 都包含 使用的调优 以及 MQ本身的配置调优

主要调优手段来自官方文档:https://rocketmq.apache.org/zh/docs/bestPractice/15bestpractice

消费速度慢:https://rocketmq.apache.org/zh/docs/bestPractice/15bestpractice#%E6%B6%88%E8%B4%B9%E9%80%9F%E5%BA%A6%E6%85%A2%E7%9A%84%E5%A4%84%E7%90%86%E6%96%B9%E5%BC%8F

猜你喜欢

转载自blog.csdn.net/qq_38571773/article/details/128706176
今日推荐