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

简介: 为什么使用消息队列,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月前
|
消息中间件 网络协议 JavaScript
MQTT常见问题之微消息队列mqtt支持ipv6失败如何解决
MQTT(Message Queuing Telemetry Transport)是一个轻量级的、基于发布/订阅模式的消息协议,广泛用于物联网(IoT)中设备间的通信。以下是MQTT使用过程中可能遇到的一些常见问题及其答案的汇总:
|
2月前
|
消息中间件 物联网 Java
MQTT常见问题之微消息队列配置失败如何解决
MQTT(Message Queuing Telemetry Transport)是一个轻量级的、基于发布/订阅模式的消息协议,广泛用于物联网(IoT)中设备间的通信。以下是MQTT使用过程中可能遇到的一些常见问题及其答案的汇总:
|
2月前
|
消息中间件 Java
springboot整合消息队列——RabbitMQ
springboot整合消息队列——RabbitMQ
76 0
|
2天前
|
消息中间件 存储 监控
写了10000字:全面学习RocketMQ中间件
以上是 V 哥在授课时整理的全部 RocketMQ 的内容,在学习时重点要理解其中的含义,正所谓知其然知其所以然,希望这篇文章可以帮助兄弟们搞清楚RocketMQ的来龙去脉,必竟这是一个非常常用的分布式应用的中间件,好了,今天的内容就分享到这,我靠!已经 00:36分,建议收藏起来,慢慢消化,创作不易,喜欢请点赞转发。
|
10天前
|
消息中间件 数据安全/隐私保护
MQTT微消息队列服务器连接报错:Error: Connection refused: Not authorized
使用MQTTX工具进行测试时,通过AccessKey创建了Client ID的用户名和密码。配置了公网接入点及端口1883,但尝试连接时出现错误。已附上工具截图:![](https://ucc.alicdn.com/pic/developer-ecology/3byii5uar64gg_36327474e991439da422f38c450ef153.png)。确认过用户名、密码和Client ID无误,问题仍未解决,期待回复!
|
23天前
|
消息中间件 存储 监控
解析RocketMQ:高性能分布式消息队列的原理与应用
RocketMQ是阿里开源的高性能分布式消息队列,具备低延迟、高吞吐和高可靠性,广泛应用于电商、金融等领域。其核心概念包括Topic、Producer、Consumer、Message和Name Server/Broker。RocketMQ支持异步通信、系统解耦、异步处理和流量削峰。关键特性有分布式架构、顺序消息、高可用性设计和消息事务。提供发布/订阅和点对点模型,以及消息过滤功能。通过集群模式、存储方式、发送和消费方式的选择进行性能优化。RocketMQ易于部署,可与Spring集成,并与Kafka等系统对比各有优势,拥有丰富的生态系统。
110 4
|
24天前
|
消息中间件 存储 负载均衡
消息队列学习之RabbitMQ
【4月更文挑战第3天】消息队列学习之RabbitMQ,一种基于erlang语言开发的流行的开源消息中间件。
17 0
|
28天前
|
消息中间件 存储 负载均衡
消息队列学习之kafka
【4月更文挑战第2天】消息队列学习之kafka,一个分布式的,支持多分区、多副本,基于 Zookeeper 的分布式消息流平台。
19 2
|
29天前
|
消息中间件 存储 缓存
消息队列学习之rocketmq
【4月更文挑战第1天】消息队列学习之rocketmq
16 0
|
2月前
|
消息中间件 存储 中间件
【SpringCloud Stream消息驱动、设计思想以及整合rabbitmq消息队列案例--学习笔记】
【SpringCloud Stream消息驱动、设计思想以及整合rabbitmq消息队列案例--学习笔记】
51 0