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月前
|
消息中间件 存储 数据库
深入学习RocketMQ的底层存储设计原理
文章深入探讨了RocketMQ的底层存储设计原理,分析了其如何通过将数据和索引映射到内存、异步刷新磁盘以及消息内容的混合存储来实现高性能的读写操作,从而保证了RocketMQ作为一款低延迟消息队列的读写性能。
|
16天前
|
消息中间件 运维 监控
云消息队列RabbitMQ实践解决方案评测报告
本报告旨在对《云消息队列RabbitMQ实践》解决方案进行综合评测。通过对该方案的原理理解、部署体验、设计验证以及实际应用价值等方面进行全面分析,为用户提供详尽的反馈与建议。
48 15
|
15天前
|
消息中间件 弹性计算 运维
阿里云云消息队列RabbitMQ实践解决方案评测报告
阿里云云消息队列RabbitMQ实践解决方案评测报告
43 9
|
11天前
|
消息中间件 监控 数据处理
解决方案 | 云消息队列RabbitMQ实践
解决方案 | 云消息队列RabbitMQ实践
24 1
|
12天前
|
消息中间件 弹性计算 运维
云消息队列RabbitMQ实践
本评测报告详细分析了阿里云云消息队列 RabbitMQ 版的实践原理、部署体验及核心优势。报告认为其在解决消息积压、脑裂难题及弹性伸缩方面表现优秀,但建议进一步细化架构优化策略和技术细节描述。部署文档详尽,对初学者友好,但仍需加强网络配置和版本兼容性说明。实际部署展示了其高可用性和成本优化能力,适用于高并发消息处理和分布式系统数据同步。为进一步提升方案,建议增加安全性配置指导、性能调优建议及监控告警系统设置。
|
25天前
|
消息中间件
手撸MQ消息队列——循环数组
队列是一种常用的数据结构,类似于栈,但采用先进先出(FIFO)的原则。生活中常见的排队场景就是队列的应用实例。在数据结构中,队列通常用数组实现,包括入队(队尾插入元素)和出队(队头移除元素)两种基本操作。本文介绍了如何用数组实现队列,包括定义数组长度、维护队头和队尾下标(front 和 tail),并通过取模运算解决下标越界问题。此外,还讨论了队列的空与满状态判断,以及并发和等待机制的实现。通过示例代码展示了队列的基本操作及优化方法,确保多线程环境下的正确性和高效性。
25 0
手撸MQ消息队列——循环数组
|
2月前
|
消息中间件 存储 Java
【揭秘】RocketMQ内部运作大揭秘:一探究竟,原来消息队列是这样工作的!
【8月更文挑战第19天】RocketMQ是一款高性能、高可用的消息中间件,在分布式系统中至关重要。它采用发布/订阅模式,支持高吞吐量的消息传递。核心组件包括管理元数据的NameServer、存储消息的Broker以及Producer和Consumer。RocketMQ支持发布/订阅与点对点两种模型,并具备复杂的消息持久化和路由机制。通过Java API示例,可轻松实现消息的发送与接收。RocketMQ凭借其出色的特性和可靠性,成为大型分布式系统首选的消息解决方案。
58 5
|
2月前
|
消息中间件 存储 缓存
一个用过消息队列的人,竟不知为何要用 MQ?
一个用过消息队列的人,竟不知为何要用 MQ?
94 1
|
2月前
|
消息中间件 网络架构
RabbitMQ消息队列常见面试题
这篇文章总结了RabbitMQ的常见面试题,涵盖了消息模型、使用场景、实现功能、消息幂等性、顺序性、堆积和丢失的避免方法,以及推模式和拉模式的区别。
55 0
|
2月前
|
消息中间件 Java Kafka
MQ 消息队列 比较
MQ 消息队列 比较
33 0