主流MQ应用场景,优缺点对比

目前主流的MQ产品

ActiveMQ RabbitMQ RocketMQ Kafka

应用场景

1. 应用解耦

场景说明:后台发货系统,发货后快递发货系统需要通知订单系统,该订单已发货。如果我们用传统的做法是,快递发货系统调用订单系统的接口,更新订单为已发货。如下图

在这里插入图片描述

传统模式的缺点:
1) 假如订单系统无法访问,则订单更新为已发货失败,从而导致发货失败;
2) 发货系统与订单系统耦合;
如何解决以上问题呢?引入应用消息队列后的方案,如下图:

在这里插入图片描述

发货系统:发货后,发货系统完成持久化处理,将消息写入消息队列,返回发货成功。
订单系统:订阅发货的消息,获取发货信息,订单系统根据信息,进行更新操作。
如上,发货系统在发货的时候不用关心后续操作了,如果订单系统不能正常使用。也不影响正常发货,实现订单系统与发货系统的应用解耦。

2. 异步处理
场景说明:用户注册后,需要发注册邮件和注册短信。传统的做法有两种1.串行的方式;2.并行方式。
(1)串行方式:将注册信息持久化后,发送注册邮件,再发送注册短信。三个业务全部完成后,返回给客户端。
在这里插入图片描述

(2)并行方式:将注册信息持久化后,发送注册邮件的同时,发送注册短信。三个业务全部完成后,返回给客户端。与串行的差别是,并行的方式可以提高处理的时间。

在这里插入图片描述

假设三个业务节点每个使用100毫秒钟,不考虑其他开销,则串行方式的时间是300ms,并行的时间可能是200毫秒。则串行的方式1秒内可处理3次请求,并行方式1秒内可处理5次请求,综上所述,传统的方式系统的性能(并发量,吞吐量,响应时间)会有瓶颈。如何解决这个问题呢?
引入消息队列,将不是必须的业务逻辑,异步处理。如下图所示

在这里插入图片描述

按照上图,用户的响应时间相当于是注册信息写入数据库的时间和将消息插入消息队列,也就是105毫秒。注册邮件,发送短信消息写入队列后,直接返回。如此消息队列异步处理后,1秒内可处理9次请求,大大提高了系统的性能。

3. 流量削峰
流量削锋也是消息队列中的常用场景,一般在秒杀或抢够活动中使用广泛。
应用场景:秒杀活动,一般会因为流量过大,应用系统配置承载不了这股瞬间流量,导致系统直接挂掉,即传说中的“宕机”现象。为解决这个问题,我们会将那股巨大的流量拒在系统的上层,即将其转移至 MQ 而不直接涌入我们的接口,此时MQ起到了缓冲作用。

在这里插入图片描述

缺点

1. 系统可用性降低
2. 系统复杂性提高
3. 一致性问题

后面的文章会详细讲解一下,如何去解决这些问题

四个MQ对比

特性ActiveMQRabbitMQRocketMQKafka
单机吞吐量万级,吞吐量比RocketMQ和Kafka要低了一个数量级万级,吞吐量比RocketMQ和Kafka要低了一个数量级10万级,RocketMQ也是可以支撑高吞吐的一种MQ10万级别,这是kafka最大的优点,就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic数量对吞吐量的影响topic可以达到几百,几千个的级别,吞吐量会有较小幅度的下降这是RocketMQ的一大优势,在同等机器下,可以支撑大量的topictopic从几十个到几百个的时候,吞吐量会大幅度下降。所以在同等机器下,kafka尽量保证topic数量不要过多。如果要支撑大规模topic,需要增加更多的机器资源
时效性ms级微秒级,这是rabbitmq的一大特点,延迟是最低的ms级延迟在ms级以内
可用性高,基于主从架构实现高可用性高,基于主从架构实现高可用性非常高,分布式架构非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用
消息可靠性有较低的概率丢失数据经过参数优化配置,可以做到0丢失经过参数优化配置,消息可以做到0丢失
功能支持MQ领域的功能极其完备基于erlang开发,所以并发能力很强,性能极其好,延时很低MQ功能较为完善,还是分布式的,扩展性好功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用,是事实上的标准
优劣势总结非常成熟,功能强大,在业内大量的公司以及项目中都有应用。偶尔会有较低概率丢失消息。而且现在社区以及国内应用都越来越少,官方社区现在对ActiveMQ 5.x维护越来越少,几个月才发布一个版本。而且确实主要是基于解耦和异步来用的,较少在大规模吞吐的场景中使用erlang语言开发,性能极其好,延时很低;吞吐量到万级,MQ功能比较完备。而且开源提供的管理界面非常棒,用起来很好用。社区相对比较活跃,几乎每个月都发布几个版本分。在国内一些互联网公司近几年用rabbitmq也比较多一些。但是问题也是显而易见的,RabbitMQ确实吞吐量会低一些,这是因为他做的实现机制比较重。而且erlang开发,国内有几个公司有实力做erlang源码级别的研究和定制?如果说你没这个实力的话,确实偶尔会有一些问题,你很难去看懂源码,你公司对这个东西的掌控很弱,基本职能依赖于开源社区的快速维护和修复bug。而且rabbitmq集群动态扩展会很麻烦,不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码,很难定制和掌控。接口简单易用,而且毕竟在阿里大规模应用过,有阿里品牌保障。日处理消息上百亿之多,可以做到大规模吞吐,性能也非常好,分布式扩展也很方便,社区维护还可以,可靠性和可用性都是ok的,还可以支撑大规模的topic数量,支持复杂MQ业务场景。而且一个很大的优势在于,阿里出品都是java系的,我们可以自己阅读源码,定制自己公司的MQ,可以掌控。社区活跃度相对较为一般,不过也还可以,文档相对来说简单一些,然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码。还有就是阿里出台的技术,你得做好这个技术万一被抛弃,社区黄掉的风险,那如果你们公司有技术实力我觉得用RocketMQ挺好的kafka的特点其实很明显,就是仅仅提供较少的核心功能,但是提供超高的吞吐量,ms级的延迟,极高的可用性以及可靠性,而且分布式可以任意扩展。同时kafka最好是支撑较少的topic数量即可,保证其超高吞吐量。而且kafka唯一的一点劣势是有可能消息重复消费,那么对数据准确性会造成极其轻微的影响,在大数据领域中以及日志采集中,这点轻微影响可以忽略。这个特性天然适合大数据实时计算以及日志收集
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
JMS(Java Message Service)和MQ(Message Queue)都是消息传递技术,用于在分布式系统中进行异步通信和解耦应用组件。 JMS是Java平台的消息传递标准,提供了一种用于创建、发送和接收消息的API。它适用于Java应用程序之间的通信,并且可以与各种消息中间件(包括MQ)集成。JMS适用于以下应用场景: 1. 发布/订阅模式:在这种模式下,消息发布者将消息发送到主题(Topic),而订阅者可以通过订阅主题来接收消息。这种模式适用于多个消费者需要同时接收消息的场景,如新闻订阅、实时数据更新等。 2. 点对点模式:在这种模式下,消息发送者将消息发送到队列(Queue),而接收者通过从队列中接收消息来消费。这种模式适用于只有一个接收者需要处理消息的场景,如任务分发、订单处理等。 MQ(Message Queue)是一种消息中间件,提供了可靠的消息传递机制,并支持多种通信协议。MQ适用于以下应用场景: 1. 异步通信:MQ可以实现异步通信,发送方将消息发送到队列中,而接收方可以在合适的时机从队列中获取消息并进行处理。这种方式可以提高系统的可靠性和性能,减少系统之间的耦合。 2. 流量削峰:当系统面临高峰期时,MQ可以作为缓冲层,接收并缓存请求,然后按照系统的处理能力逐步消费。这样可以避免系统过载,保证系统的稳定性。 3. 系统解耦:使用MQ可以将系统解耦,各个模块之间通过消息进行通信,而不是直接调用对方的接口。这样可以降低系统之间的依赖性,提高系统的灵活性和可维护性。 总而言之,JMS适用于Java应用程序之间的通信,而MQ适用于各种异步通信和解耦场景。它们可以根据具体的需求进行选择和使用

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值