消息中间件-有什么优缺点?

首先,我们先来确认下业界使用MQ的三大场景。

1 消息中间件的优点:

1.1 场景一:

A 系统发送数据到 BCD 三个系统,通过接口调用发送。如果 E 系统也要这个数据呢?那如果 C 系统现在不需要了呢?A 系统负责人几乎崩溃…

在这里插入图片描述
在这个场景中,A系统和各个系统之间有复杂的耦合关系;
如果使用MQ,A系统生产一条数据,发送到MQ中,那个系统需要数据,自己就去MQ中消费。
如果有新的系统需要数据,直接从MQ中消费即可;
如果某个系统不需要这条数据,我们就取消对MQ的消费;
A系统就不需要关心数据要发给谁,不需要维护这个代码,也不要考虑人家是否调用成功、失败超时等情况。
在这里插入图片描述
总结:在这个场景中,我们通过发布订阅消息,A系统就和其他系统之间,完成了解耦。

1.2 场景二:

A系统 ,每天22个小时,每秒并发量在30个数据左右。只有在晚上8点-10点昨天,并发量在5k+左右。但是系统是基于MySQL数据库的,大量的数据请求涌入mysql,会导致mysql数据库崩溃。(一般mysql数据库也就是每秒2000个请求)
在这里插入图片描述
如果使用MQ,每秒5k请求写入MQ,A系统每秒中处理2k个请求。因为MYSQL的数据请求瓶颈的问题,所以A系统每秒从MQ中拉去2k个请求来处理。哪怕是业务高峰的时候来临,A系统也不会挂掉。因为它每秒就处理2k+请求。
在这里插入图片描述

这个短暂的高峰期积压是 ok 的,因为高峰期过了之后,每秒钟就 50 个请求进 MQ,但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说,只要高峰期一过,A 系统就会快速将积压的消息给解决
总结:这样的场景适用于解决系统的消峰的问题。比如大量的用户注册发送短信验证等;

1.3 场景三:

如果场景三描述的是A系统受到一个请求,需要写本地库,花费3ms,而其中还需要调用B系统,花费300ms,c系统 450ms,d系统 200ms。这样这个一个业务就要花费3+300+450+200=953ms。正常的用户请求正常控制在200ms内完成。等待1s 用户体验很差。
在这里插入图片描述
如果使用MQ,那么A系统从接受这个请求到返回响应给用户。总时长8ms。对于用户来说,这样的用户体验很好。
在这里插入图片描述
总结:在这个场景中。我们看到了mq的异步处理的作用。

2 消息中间件也有缺点:

2.1. 系统可用性降低

系统引入的外部依赖越多,越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了,人 ABCD 四个系统好好的,没啥问题,你偏加个 MQ 进来,万一 MQ 挂了咋整,MQ 一挂,整套系统崩溃的,你不就完了?

2.2.系统复杂度提高

硬生生加个 MQ 进来,你怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性?头大头大,问题一大堆,痛苦不已。

2.3.一致性问题

A 系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是 BCD 三个系统那里,BD 两个系统写库成功了,结果 C 系统写库失败了,咋整?你这数据就不一致了。

所以消息队列实际是一种非常复杂的架构,你引入它有很多好处,但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉,做好之后,你会发现,妈呀,系统复杂度提升了一个数量级,也许是复杂了 10 倍。但是关键时刻,用,还是得用的。

3 消息中间件的对比

在这里插入图片描述

4 建议

中小型公司,技术实力较为一般,技术挑战不是特别高,用 RabbitMQ 是不错的选择;大型公司,基础架构研发实力较强,用 RocketMQ 是很好的选择。

大数据领域的实时计算、日志采集等场景,用 Kafka 是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范

  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值