消息队列的使用场景和优缺点

248 阅读5分钟

为什么使用消息队列

项目中为什么使用消息队列作为中间件,其作用是什么,说到作用无非就是其核心的特点. 消息队列作为一种对消息处理的中间件,其主要作用有三点: 解耦 异步 肖峰

解耦

当一个系统或者模块,调用多个系统或者模块,相互之间调用很复杂,维护起来很麻烦。这个时候我们可以将调用的多个系统或者模块进行解耦,拆成多个服务,通过消息队列链接 进行异步解耦

异步

通过上面的解耦我们了解到系统或者模块的调用通过消息队列链接,调用的时候我们之间给消息队列发送消息就行,不用等调用的系统或者模块反馈。这个时候就是通过异步的方式,尽快的将整个业务流程走完。

肖峰

当很多请求过来的时候,系统处理不过来,这个时候不能等一个请求处理完了,再处理另外一条,这样给用户的反馈时间比较长。这个时候,我们可以将请求信息放入到消息队列中,让后面的消息者慢慢去处理这些大量的消息,从而达到肖峰的作用。

引入消息队列的缺点

我们都知道在程序中 空间和时间两者往往存在冲突,中间件也是一样,一样有有缺点。总之 一句话 '适合自己的才是最好的'。

系统可用性降低

引入消息队列,会导致系统对其的依赖性增强,当消息队列不可用的时候,我们的系统就可能页不能用的状态。

系统复杂性增加

引入消息队列, 我们需要考虑消息的消费顺序,丢失等问题。

一致性问题

引入消息队列后,我们知道生产者只往消息队列中放入消息,并不知道消费者后面的处理情况,是成功还是失败? 这个时候我们需要考虑数据一致性问题

消息队列对比

特征ActiveMQRabbitMQRocketMQKafka
单机吞吐量万级,吞吐量比RocketMQ和Kafka要低了一个数量级万级,吞吐量比RocketMQ和Kafka要低了一个数量级10万级,RocketMQ也是可以支撑高吞吐的一种MQ10万级别,这是kafka最大的优点,就是吞吐量高。
topic数量对吞吐量的影响topic可以达到几百,几千个的级别,吞吐量会有较小幅度的下降 这是RocketMQ的一大优势,在同等机器下,可以支撑大量的topictopic从几十个到几百个的时候,吞吐量会大幅度下降 所以在同等机器下,kafka尽量保证topic数量不要过多。如果要支撑大规模topic,需要增加更多的机器资源
时效性ms级微秒级,这是rabbitmq的一大特点,延迟是最低的ms级延迟在ms级以内
可用性高,基于主从架构实现高可用性高,基于主从架构实现高可用性非常高,分布式架构非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用
消息可靠性有较低的概率丢失数据经过参数优化配置,可以做到0丢失经过参数优化配置,消息可以做到0丢失
功能支持MQ领域的功能极其完备基于erlang开发,所以并发能力很强,性能极其好,延时很低MQ功能较为完善,还是分布式的,扩展性好功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用,是事实上的标准
优劣势总结非常成熟,功能强大,在业内大量的公司以及项目中都有应用,偶尔会有较低概率丢失消息。而且现在社区以及国内应用都越来越少,官方社区现在对ActiveMQ 5.x维护越来越少,几个月才发布一个版本。而且确实主要是基于解耦和异步来用的,较少在大规模吞吐的场景中使用erlang语言开发,性能极其好,延时很低;吞吐量到万级,MQ功能比较完备 而且开源提供的管理界面非常棒,用起来很好用接口简单易用,而且毕竟在阿里大规模应用过,有阿里品牌保障,日处理消息上百亿之多,可以做到大规模吞吐,性能也非常好,分布式扩展也很方便,社区维护还可以,可靠性和可用性都是ok的,还可以支撑大规模的topic数量,支持复杂MQ业务场景,社区活跃度相对较为一般,不过也还可以,文档相对来说简单一些,然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码kafka的特点其实很明显,就是仅仅提供较少的核心功能,但是提供超高的吞吐量,ms级的延迟,极高的可用性以及可靠性,而且分布式可以任意扩展 同时kafka最好是支撑较少的topic数量即可,保证其超高吞吐量。而且kafka唯一的一点劣势是有可能消息重复消费,那么对数据准确性会造成极其轻微的影响,在大数据领域中以及日志采集中,这点轻微影响可以忽略 这个特性天然适合大数据实时计算以及日志收集

总结

我接触的项目大部分就是些对消息的敏感程度不是很高,中间件简单部署的ActiveMQ。项目中主要是简单的发消息和收消息,ActiveMQ使用使用。其他的消息队列都自己玩过,每个消息队列都有自己的优缺点。大家可以结合上面的表格 选择适合自己的消息队列中间件。