关于MQ的几件小事(一)消息队列的用途、优缺点、技术选型
1.为什么使用消息队列?
(1)解耦:可以在多个系统之间进行解耦,将原本通过网络之间的调用的方式改为使用MQ进行消息的异步通讯,只要该操作不是需要同步的,就可以改为使用MQ进行不同系统之间的联系,这样项目之间不会存在耦合,系统之间不会产生太大的影响,就算一个系统挂了,也只是消息挤压在MQ里面没人进行消费而已,不会对其他的系统产生影响。![不使用MQ的情况.png](https://upload-images.jianshu.io/upload_images/8494967-8a6c27beefa1978e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
![使用MQ进行解耦之后.png](https://upload-images.jianshu.io/upload_images/8494967-73713abdc4ccf927.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
![不使用MQ情况.png](https://upload-images.jianshu.io/upload_images/8494967-248455c8863c542e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
![使用MQ进行异步之后.png](https://upload-images.jianshu.io/upload_images/8494967-9840c1edd9d24125.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
![使用MQ进行削峰.png](https://upload-images.jianshu.io/upload_images/8494967-5e386c784e984ab3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
2.消息队列有什么优点和缺点?
优点:1、对结构复杂、设计系统多的操作进行解耦操作,降低系统的操作复杂度、降低系统的维护成本。
2、对一个可以进行异步操作的一些系统操作进行异步,减小操作的响应时间,提供更好的用户体验。
3、可对高流量进行削峰,保证系统的平稳运行。
缺点:1、系统可用性降低。比如在系统中引入MQ,那么万一MQ挂了怎么办呢?一般而言,引入的外部依赖越多,系统越
脆弱,每一个依赖出问题都会导致整个系统的崩溃。
2、系统复杂度提高。需要考虑MQ的各种情况,比如:消息的重复消费、消息丢失、保证消费顺序等等......
3、数据一致性问题。比如A系统已经给客户返回操作成功,这时候操作BC都成功了,操作D却失败了,导致数据不
一致。
3.kafka、activemq、rabbitmq、rocketmq都有什么优点和缺点啊?
特性 | ActiveMQ | RabbitMQ | RocketMQ | kafka |
---|---|---|---|---|
单机吞吐量 | 万级,吞吐量比RocketMQ和kafka要低一个数量级 | 万级,吞吐量比RocketMQ和kafka要低一个数量级 | 10万级,RocketMQ也是可以支撑高吞吐的一种MQ | 10万级别,kafka最大优点就是吞吐量大,一般配合大数据类的系统来进行实时数据计算、日志采集等场景。 |
topic数量对吞吐量的影响 | topic可以达到几百、几千个的级别,吞吐量会有小幅度的下降。这是RocketMQ的一大优势,可在同等数量机器下支撑大量的topic | topic从几十个到几百个的时候,吞吐量会大幅下降。所以在同等机器数量下,kafka尽量保证topic数量不要过多。如果支撑大规模topic需要增加更多的机器 | ||
时效性 | ms级 | 微秒级,这是rabbitmq的一大特点,延迟是最低的 | ms级 | 延迟在ms级以内 |
可用性 | 高,基于主从架构实现可用性 | 高,基于主从架构实现可用性 | 非常高,分布式架构 | 非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用 |
消息可靠性 | 有较低的概率丢失数据 | 经过参数优化配置,可以做到0丢失 | 经过参数配置,消息可以做到零丢失 | |
功能支持 | MQ领域的功能及其完备 | 基于erlang开发,所以并发性能极强,性能极好,延时低 | MQ功能较为完备,分布式扩展性好 | 功能较为简单,主要支持加单MQ功能 |
优势 | 非常成熟,功能强大,在业内大量公司和项目中都有应用 | erlang语言开发,性能极好、延时很低,吞吐量万级、MQ功能完备,管理界面非常好,社区活跃;互联网公司使用较多 | 接口简单易用,阿里出品有保障,吞吐量大,分布式扩展方便、社区比较活跃,支持大规模的topic、支持复杂的业务场景,可以基于源码进行定制开发 | 超高吞吐量,ms级的时延,极高的可用性和可靠性,分布式扩展方便 |
劣势 | 偶尔有较低概率丢失消息,社区活跃度不高 | 吞吐量较低,erlang语音开发不容易进行定制开发,集群动态扩展麻烦 | 接口不是按照标准JMS规范走的,有的系统迁移要修改大量的代码,技术有被抛弃的风险 | 有可能进行消息的重复消费 |
应用 | 主要用于解耦和异步,较少用在大规模吞吐的场景中 | 都有使用 | 用于大规模吞吐、复杂业务中 | 在大数据的实时计算和日志采集中被大规模使用,是业界的标准 |
综上所述,总结如下:
一般业务系统要引入MQ,最早大家都用ActiveMQ,但现在用的不多了。没有经过大规模吞吐场景的验证,社区也不活跃,不推荐再使用。
后来大家开始用rabbitMQ,但是它是使用erlang语言开发的,如果不精通erlang,对公司而言,几乎处于不可控的状态,单其是开源的,社区活跃度高,拥有比较稳定的支持。
现在越来越多的公司开始使用RocketMQ,但是要小心被抛弃的风险。如果公司有实力自己去维护开发,推荐使用。否则还是选择RabbitMQ。
如果实在大数据的实时计算、日志采集等领域,用kafka是业界标准。
所以,对于中小型公司,技术实力一般的,应该用rabbitmq,对于大公司,基础架构研发能力强大的,推荐使用RocketMQ。
下一篇《如何保证消息队列的高可用》
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 用 C# 插值字符串处理器写一个 sscanf
· Java 中堆内存和栈内存上的数据分布和特点
· 开发中对象命名的一点思考
· .NET Core内存结构体系(Windows环境)底层原理浅谈
· C# 深度学习:对抗生成网络(GAN)训练头像生成模型
· 趁着过年的时候手搓了一个低代码框架
· 本地部署DeepSeek后,没有好看的交互界面怎么行!
· 为什么说在企业级应用开发中,后端往往是效率杀手?
· 用 C# 插值字符串处理器写一个 sscanf
· 乌龟冬眠箱湿度监控系统和AI辅助建议功能的实现