MQ 学习日志(二) 为什么使用消息队列,mq有什么优点和缺点

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 为什么使用消息队列,mq有什么优点和缺点

为什么使用消息队列,mq有什么优点和缺点,kafka,activemq,rabbitmq,rocketmq都有什么优点?

先说一下MQ的使用场景吧

其实场景有很多,但是比较核心的有三个:解耦,异步,消峰

解耦

现场画个图说明一下,A系统发送一个数据到BCD三个系统,接口调用发送,如果E系统也要这个数据呢,那如果C系统现在不需要了呢,现在A系统又要发送第二种数据了呢,A系统负责人崩溃中,再来点更加崩溃的事情,A系统要时时刻刻考虑BCDE四个系统如果挂了怎么办,要不要重新发送,要不要把消息存放起来,等等。。。

异步

现场画个图说明一下,A系统接收一个请求,需要在自己本地写库,还需要再BCD三个系统写库,自己本地写库需要3MS,BCD三个系统分别写库要300ms,450ms,200ms,最终请求延时是3+450+300+200,接近1s,用户感觉这是个什么东西,慢死了

削峰

每天0-11点,A系统风平浪静,每秒并发请求数量也就100个,结果每次一到11点-1点,每秒并发请求数量突然暴增到1万条,但是系统最大的处理能力也就只能是每秒钟处理1000个请求,怎么办。。。

消息队列有什么优点和缺点

优点:就是再特殊场景下其对应的好处,解耦,异步,消峰

缺点:

  1. 系统可用性降低:系统引入的外部依赖越多,越容易挂掉
  2. 系统复杂性提高:MQ加进来后,会有很多麻烦的问题:重复消费,消息丢失,怎么保证消息的顺序性,等等
  3. 一致性问题:A系统处理完了,返回给用户成功,用户以为操作成功了,但是C系统挂了,导致数据不一致,

所以MQ是一种非常复杂的架构,引入他有很多的好处,但是也得针对它带来的坏处做各种二外的技术方案和架构来规避,最终可能导致系统的复杂度提升了很大的量级,但是关键时刻改用还是得用

Kafka,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丢失 经过参数优化配置,消息可以做到0丢失
核心特点 MQ领域功能机器完备 基于Erlang语言开发,所以并发能力很强,性能极其好,延时很低 MQ功能较为完善,还是分布式的,拓展性好 功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用,是事实上的标准
优劣势总结 非常成熟,功能强大,在业内大量的公司以及项目都有应用,偶尔会有较低的概率丢失消息,而且现在社区以及国内应用都越来越少,官方社区现在对ActiveMq5.x维护也越来越少,而且确实主要是基于异步和解耦来用的,较少在大规模吞吐的场景中使用 erlang语言开发,性能极其好,而且开源提供的管理界面非常好,但是问题也是显而易见的,RabbitMQ确实吞吐量会低一些,这是因为他做的实现机制比较重,而且erlang开发,国内能做erlang源生的公司太少,导致公司对于该产品的掌控太少,只能依赖于开源社区以及官方修复BUG,并且RabbitMQ集群动态拓展会很麻烦,主要是erlang语言本身带来的问题,很难读懂源码,很难定制和掌控 接口简单易用,而且毕竟在阿里大规模应用过,有阿里品牌保障日处理消息上百亿之多,可以做到大规模吞吐,性能也非常好,分布式拓展也很方便,社区维护还可以,可靠性和可用性都是ok的,还可以支撑大规模的topic数量,支持复杂MQ业务场景,并且我们可以自己阅读源码,定制自己公司的MQ,可以掌控,社区活跃度相对来说一般,文档相对来说简单一点,但是接口这块不是按照标准的JMS规范走的,有些系统迁移需要修改大量的代码,还有就是阿里的技术,需要做好这个技术一旦被抛弃,社区黄掉的风险,需要公司有一定的技术实力 kafka的特点其实很明显,就是仅仅提供较好的核心功能,但是提供超高的吞吐量,ms级的延迟,较高的可用性以及可靠性,而且分布式可以任意拓展,同时kafka最好是支撑教师奥德topic数量即可,保证其超高吞吐量,而且kaafka唯一的劣势是有可能消息重复消费,这样对于数据的准确性会造成机器轻微的影响,再大数据领域中以及日志采集中,这点轻微影响可以忽略,这个特性天然适合各大数据试试计算以及日志收集
目录
相关文章
|
2月前
|
消息中间件 JSON Java
开发者如何使用轻量消息队列MNS
【10月更文挑战第19天】开发者如何使用轻量消息队列MNS
93 5
|
2月前
|
消息中间件 安全 Java
云消息队列RabbitMQ实践解决方案评测
一文带你详细了解云消息队列RabbitMQ实践的解决方案优与劣
89 8
|
1月前
|
消息中间件 存储 Kafka
MQ 消息队列核心原理,12 条最全面总结!
本文总结了消息队列的12个核心原理,涵盖消息顺序性、ACK机制、持久化及高可用性等内容。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
|
2月前
|
消息中间件
解决方案 | 云消息队列RabbitMQ实践获奖名单公布!
云消息队列RabbitMQ实践获奖名单公布!
|
2月前
|
消息中间件 存储 弹性计算
云消息队列RabbitMQ实践
云消息队列RabbitMQ实践
|
2月前
|
Arthas 监控 Java
JVM知识体系学习七:了解JVM常用命令行参数、GC日志详解、调优三大方面(JVM规划和预调优、优化JVM环境、JVM运行出现的各种问题)、Arthas
这篇文章全面介绍了JVM的命令行参数、GC日志分析以及性能调优的各个方面,包括监控工具使用和实际案例分析。
68 3
|
2月前
|
消息中间件 存储 监控
解决方案 | 云消息队列RabbitMQ实践
在实际业务中,网站因消息堆积和高流量脉冲导致系统故障。为解决这些问题,云消息队列 RabbitMQ 版提供高性能的消息处理和海量消息堆积能力,确保系统在流量高峰时仍能稳定运行。迁移前需进行技术能力和成本效益评估,包括功能、性能、限制值及费用等方面。迁移步骤包括元数据迁移、创建用户、网络打通和数据迁移。
71 4
|
2月前
|
存储 Prometheus NoSQL
大数据-44 Redis 慢查询日志 监视器 慢查询测试学习
大数据-44 Redis 慢查询日志 监视器 慢查询测试学习
33 3
|
2月前
|
Python
log日志学习
【10月更文挑战第9天】 python处理log打印模块log的使用和介绍
42 0
|
5月前
|
消息中间件 C语言 RocketMQ
消息队列 MQ操作报错合集之出现"Connection reset by peer"的错误,该如何处理
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
下一篇
DataWorks