如何进行消息队列的选型

如何进行消息队列的选型

之前已经将这个专栏差不多浏览一遍了,但是回过头来发现有些知识还是比较模糊,一方面是因为有些东西越看越来劲,就直接看下一章节了,还有就是没有认真完成玥哥布置的课后作业,没关系,经典需要重复,这一次加上做笔记,再学一次,温故知新~

另外我会在博客上面增加一个消息队列的专栏,用来分享每个章节的学习感悟,keep going~

1.消息队列的选择

  • 开源:出现问题可以查看源码解决,而不是被动的等待新版本发布

  • 社区活跃:其他人也会遇到相同的使用问题

  • 生态环境:kafka的生态环境和大数据环境完全匹配兼容

  • 基本特性:作为消息队列,要保证不丢消息,高可用,并且性能也要可观,能够满足绝大多数场景的性能需求

2.可供选择的消息队列

目前没有一款消息队列能够做到一统天下,这一块还是比较多元化的, 需要我们熟悉理解每个消息队列的特性,然后根据具体的业务场景,选用合适的消息队列

  • RabbitMQ

关键词就是轻量级,使用Erlang语言编写,支持AMQP协议

一个特色就是在生产者和队列之前加入了Exchange模块进行路由配置,路由规则是比较灵活的,可以手动进行配置

缺点:

1.对消息积压的支持并不好,他的设计理念认为消息队列就是一个通道,当消息积压时,性能会急剧下降

2.性能不如其他的消息队列,正常情况下,普通的业务场景是可以满足的,但是当系统对性能要求比较高的时候,就不要选择这个了

3.这玩意是使用Erlang语言开发的,比较冷门,不容易进行二次开发

  • RocketMQ

阿里爸爸开发出来的消息队列,经历了世界上最大并发量、吞吐量的双十一的考验,可见是多么牛逼

使用Java语言写的,因为阿里主要搞电商,RcoketMQ对在线业务的时延响应做了很多优化

RocketMQ方方面面都不错如果非要挑出什么缺点,那么就是和kafka相比,生态还不够好

  • kafka

消息队列这一块扛把子的老大哥,之前刚出来的时候是为了解决海量日志的,那时候还不能保证丢消息,但是发展到现在已经可以确保消息不丢了,整体设计采用大量的异步和批处理的思想,在所有消息队列里面性能算是最好的,但是正是因为kafka采用异步、批处理的思想,所以对于一些实时性比较高的在线业务来讲,时延会比较高,因为kafka的很多地方都是攒够一波一起发这样做的,如果消息不是那么多的时候,时延就会比较大

  • JMQ

这是老东家的黄金产品,这里还是提一嘴,刚去京东实习的时候,我第一天的第一个问题就是,为什么京东要自己搞JMQ?市面上已经有的不香嘛?经历了这么长时间我的理解,首先最主要的还是kafka的时延问题,因为京东也都是在线业务系统,如果用户下单之后,软件一直在那里转圈这种情况发生的话,还是会非常影响用户体验的,所以需要时延比较低的消息队列,那么为什么不选用RocketMQ呢?我想这就不是非技术的原因了,很复杂,咱也不多说,很好想明白。JMQ在内测的时候,整体的性能、稳定性都是不错的, 为京东的618和双11也是立下了汗马功劳,目前只是开源了一部分核心代码,叫做joy-queque,其他开源事宜后面会有进展的,期待!

说了这么多,做个总结,我们应该如何选择消息队列?

如果消息队列不是业务系统的核心,我们对消息队列也没什么特别的要求,那么选择Rabbit就可以了,他就是为了开箱即用的特点诞生的,轻量级,也很OK

如果业务系统对时延要求比较高,吞吐量也比较大的话,那么选用RocketMQ或者JMQ吧,不仅可以保证低时延,也可以保证金融级别的稳定

如果需要处理海量的数据,或者说系统中使用了大数据生态系统中的东西,那么就直接选用kafka, 性能好,生态好

不过我的了解是,目前很多的系统都是采用了不止一种消息队列,而是采用组合的方式,例如:RocketMQ+Kafka,分别用于在线业务和日志,这样就可以兼顾两个的优点,随之带来的问题就是开发维护成本变高了

Copyright: 采用 知识共享署名4.0 国际许可协议进行许可

Links: https://hadoo666.top/archives/如何进行消息队列的选型md