彻底理解消息队列的作用及如何选择
一.为什么要使用消息队列?使用消息队列,其实是须要根据实际业务场景来的,一般都是实际开发中,遇到了某种技能挑战,如果不使用MQ的话,业务实现起来比较贫苦,但是通过MQ就可以更快捷高效的实现业务功能。
消息队列使用有很多利益,比较核心的三个利益:解耦、异步、削峰。
1.异步
https://i-blog.csdnimg.cn/direct/afa402ccdac84af0bb53e6ba921afbd1.png
例如,用户下一个订单,它涉及到扣库存,同时会生成订单,然后向用户发送短信服务和积分服务,如果这个流程实现成一个同步的过程,那么业务线就很长,耗时就特殊长,须要15ms,但如果中间参加一个消息队列,这种情况,用户下单,然后扣库存,生成订单,只要把消息写入消息队列,这时它的业务就竣事了,对于用户来说,只须要耗时6ms,比起前面的15ms,这种方式可以异步进步用户的相应时间,后面这个消息再通过异步的方式发给了短信服务和积分服务;
如果我们在进行短信发送的时候,好比短信的第三方(移动、联通、电信)宕机了,如果接纳的是同步的方式,那么用户的下单就不能成功,但是如果参加了消息队列,其实是没有任何影响的,就算宕机,用户也可以正常下单,等短信服务规复后,这个消息依然可以通过异步的方式发给用户,这就可以避免第三方服务宕机带来的不好影响。
2.解耦
https://i-blog.csdnimg.cn/direct/9019373bab424d1ca6952f0079590bbb.png
最开始生成订单后的消息只须要发送给短信服务和积分服务,但是后续业务扩大,我们另有要把消息发送给营销服务和进行数据分析的业务场景,如果此时没有消息队列的情况下,是须要去修改生成订单后的业务处理逻辑,如许的代码就具有耦合性,但是如果参加了消息队列,这个时候其实是解耦的,后续新增功能对这个条消息的处理,对前面的业务系统是没有任何影响的,本质上新增两个服务,我只须要新增两个消费者去定订阅相干的主题就可以了,如许这条消息依然可以发到对于的服务中,解耦后可以进步系统可用性和扩展性,哪怕后续再新增10个、100个业务场景,对原来的业务代码的侵入性也是相当小的。
3.削峰
https://i-blog.csdnimg.cn/direct/fa15b112556a4217961a2aad0855d479.png
在我们日程的业务中,业务的处理量其实是不均匀的,好比天天0点到16 点,系统风平浪静,每秒并发哀求数量就100个,效果每次一到16 点至23点,每秒并发哀求数量忽然会暴增到1万条,但是系统的后端服务的最大的业务处理本事就只能是每秒钟处理1000个哀求,多余的9000个哀求,是处理不了的,那么这个时候就可以使用消息队列进行流量的削峰,让系统可以平缓的处理突增的哀求,由于消息队列里面有一个很重要的功能,是可以把过来的哀求进行短暂的存储的,也就是说每秒钟多于的9000条哀求,是可以存在消息队列中,让系统慢慢去处理这些短暂存储的哀求,相当于用时间换空间,让系统平缓的处理突增的哀求。
二.如何选择合适的消息队列?
这里针对比较常用的RabbitMQ、Kafka、RocketMQ三者做区分
1.RabbitMQ
RabbitMQ 有一个生产者(Producers)和一个消费者(Consumers),首先作为生产者,发送消息给一个叫做交换器的东西(Exchanges),然后交换器会把消息路由到一个它对应的队列(Queues),然后消费者直接拿到这个队列里面的消息,进行对应的消费。
https://i-blog.csdnimg.cn/direct/74bc2badde174e7ea60445f907bdc2bb.png
(1)根本介绍
1)RabbitMQ 于 2007 年发布,是使用 Erlang 编程语言编写的,最早是为电信行业系统之间的可靠通信计划的,也是少数几个支持 AMQP 协议的消息队列之一;
2)RabbitMQ 的轻量级、迅捷是它的宣传口号,也很明确地表明了 RabbitMQ 的特点:Messaging that just works,开箱即用的消息队列,也就是说,RabbitMQ 是一个相当轻量级的消息队列,非常容器部署和使用;
3)RabbitMQ 的客户端支持的编程语言大概是全部消息队列中最多的。
(2)存在的问题
1)RabbitMQ 对消息堆积的支持并不好,当大量消息积压的时候,会导致 RabbitMQ 的性能急剧降落;
2)RabbitMQ 的性能是这几个消息队列(相对于Kafka、RocketMQ)中最差的,大概每秒钟可以处理几万到十几万条消息,如果应用对消息队列的性能要求非常高,那不要选择 RabbitMQ,比较适用于中小型公司,如果是大项目不太顺应,由于他的并发量并不高;
3)RabbitMQ 使用的编程语言 Erlang,扩展和二次开发成本高。
2.Kafka
Kafka其实是依赖于Zookeeper的,安装Kafka是须要安装Zookeeper来做服务的注册和发现的,它有一个生产者(Producers)和一个消费者(Consumers),只是说它在处理的时候,可以可以进行分布式的部署,可以部署多台Broker,这是Kafka的一个特点。
https://i-blog.csdnimg.cn/direct/19e7104f270a456781ae8203f2d411c2.png
(1)根本介绍
1)Apache Kafka 是一个分布式消息发布订阅系统,它最初由 Linkedln 公司基于独特的计划实现为一个分布式的日记提交系统,之后成为 Apache 项目的一部门;
2)在早期的版本中,为了得到极致的性能,在计划方面做了很多的捐躯,好比不保证消息的可靠性,大概会丢失消息,也不支持集群,功能上也比较简陋,这些捐躯对于处理海量日记这个特定的场景都是可以担当的,但是,随后几年 Kafka 逐步补齐了这些短板,当下的 Kafka 已经发展为一个非常成熟的消息队列产品,无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求。
3)Kafka与周边生态系统的兼容性是最好的没有之一,尤其在大数据和流计算领域,险些全部的相干开源软件系统都会优先支持 Kafka;
4)Kafka 性能高效、可扩展良好并且可以磁盘持久化,它的分区特性,可复制和可容错都是不错的特性,Kafka 使用 Scala 和 Java 语言开发,计划上大量使用了批量和异步的头脑,使得 Kafka 能做到超高的性能,Kafka 的性能,尤其是异步收发的性能,是三者中最好的,但与 RocketMQ 并没有量级上的差异,大约每秒钟可以处理几十万以致上百万条消息;
5)在有足够的客户端并发进行异步批量发送,并且开启压缩的情况下,Kafka 的极限处理本事可以超过每秒 2000 万条消息。
(2)存在的问题
Kafka 异步批量的计划带来的问题是,它的同步收发消息的相应时延比较高,由于当客户端发送一条消息的时候,Kafka 并不会立即发送出去,而是要等一会儿攒一批消息再发送,在它的 Broker中,很多地方都会使用这种先攒一波再一起处理的计划,当你的业务场景中,每秒钟消息数量没有那么多的时候,Kafka 的时延反而会比较高,所以,Kafka 不太得当在线业务场景,topic达到上百个时,吞吐量会大幅降落(好比,像电商场景,topic是相当的多,kafka就并不适用,所以它比较适用于日记场景,里面的topic相对来说比较少)。
3.RocketMQ
RocketMQ 也是一个分布式的,它可以部署Master节点,也可以部署Slave节点,也可以多Matster、多Slave的,它里面另有一个NameServer,这个是可以用来代替Zookeeper来完成服务的注册和发现。
https://i-blog.csdnimg.cn/direct/6eb32f17f4884e7095b1427248343283.png
(1)根本介绍
1)RocketMQ 是阿里巴巴在 2012 年开源的消息队列产品,用Java 语言实现,在计划时参考了Kafka,并做出了自己的一些改进,厥后捐赠给 Apache 软件基金会,2017 正式毕业,成为Apache 的顶级项目,RocketMQ 在阿里内部被广泛应用在订单、交易、充值、流计算、消息推送、日记流式处理、Binglog 分发等场景,履历过多次双十一磨练,它的性能、稳定性和可靠性都是值得信任的;
2)RocketMQ 有着不错的性能,稳定性和可靠性,具备一个现代的消息队列应该有的险些全部功能和特性,并且它还在持续的发展中,阿里另有很多人在进行维护;
3)RocketMQ 有非常活跃的中文社区,大多数问题可以找到中文的答案,RocketMQ 使用 Java 语言开发,源代码相对比较容易读懂,容易对 RocketMQ 进行扩展大概二次开发;
4)RocketMQ 对在线业务的相应时延做了很多的优化,大多数情况下可以做到毫秒级的相应,如果你的应用场景很在意相应时延,那应该选择使用 RocketMQ;
5)RocketMQ 的性能比 RabbitMQ 要高一个数量级,每秒钟大概能处理几十万接近上百万条消息。
(2)存在的问题
RocketMQ 的劣势是与周边生态系统的集成和兼容程度不够(由于它发展的比较晚,而且是Java开发,好比对C、C++、GO等语言的兼容性程度不够)。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
页:
[1]