一、选择消息队列产品的基本标准
在消息队列的技术选型上,并不存在说哪个消息队列就是“最好的”。常用的几个消息队列,每个产品都有自己的优势和劣势,需要根据现有系统的情况,选择最适合的那款产品。
技术产品的及格标准:
- 必须是开源产品:如果遇到Bug至少有机会通过修改源代码迅速修复或规避,解决燃眉之急。
- 必须是近年来比较流行并且有一定社区活跃度的产品:流行的好处是,只要使用的场景不太冷门,遇到的Bug都可以找到解决办法。
- 流行的产品与周边生态系统会有一个比较好的集成和兼容:比如kafka和Flink就有比较好的兼容性,Flink内置了kafka的Data Sourse,使得你不用自己开发一个Flink的Data Source。
消息队列产品的及格标准:
- 消息的可靠传递:确保不丢消息。
- Cluster:支持集群,确保不会因为某个节点宕机导致服务不可用,当然也不能丢消息。
- 性能:具备足够好的性能,能满足绝大多数场景的性能要求。
二、可供选择的消息队列产品
1、RabbitMQ
介绍:
- 使用Erlang语言编写,最早是为电信行业系统之间的可靠通讯性设计的,也是少数几个支持AMQP协议的消息队列。
- 轻量级、迅速,开箱即用,非常容易部署和使用。
- 有一个特色的功能是支持非常灵活的路由配置。它在生产者和队列之间增加了一个Exchange模块,可以理解为交换机,根据配置的路由规则将生产者发出的消息分发到不同的队列中。
- 客户端支持的编程语言是所有消息队列中最多的。
劣势:
- 对消息堆积的支持并不好。在它的设计理念中,消息队列是一个管道,大量的消息积压不是正常的情况,应当尽量避免。当大量消息积压时,会导致性能急剧下降。
- RabbitMQ的性能是介绍的几个消息队列中最差的,它大概每秒可以处理几万到几十万条消息,这个性能也足够支撑绝大多数场景。不过,如果你的应用对消息队列的性能要求非常高,那就不要选择RabbitMQ。
- 小众的编程语言Erlang。如果想基于RabbitMQ做一些扩展和二次开发,建议你慎重考虑可持续维护的问题。
RabbitMQ 官方文档:https://www.rabbitmq.com/documentation.html
2、RocketMQ
介绍:
- RocketMQ是阿里巴巴2012年开源的产品,后来捐赠给Apache软件基金会。2017年正式成为Apache的顶级项目。
- 阿里内部也是使用RocketMQ作为支撑其业务的消息队列,经历多次“双十一”考验,它的性能、稳定性和可靠性都是值得信赖的。
- 有非常活跃的中文社区,大多数问题都可以找到中文答案。使用Java语言开发,它的贡献者大多数为中国人,源代码相对比较易懂或易进行扩展和二次开发。
- RocketMQ对在线业务的响应时延做了很多优化,大多数情况下可以做到毫秒级的响应,如果你的应用场景很在意响应时延,那应该选择使用RocketMQ。
- RocketMQ的性能比RabbitMQ要高一个数量级,每秒大概能处理几十万条消息。
劣势:
- 作为国产消息队列,相比国外比较流行的同类产品,与周边生态系统的集成和兼容程度要略逊一筹。
RocketMQ 官方文档:https://rocketmq.apache.org/docs/quick-start/
RocketMQ 中国开发者中心:http://rocketmq.cloud/zh-cn/
3、Kafka
介绍:
- 最早是由LinkedIn开发,目前也是Apache的顶级项目。最初的设计目的是用于处理海量的日志。
- 与周边生态系统的兼容性是最好的,尤其在大数据和流计算领域,几乎所有的相关开源软件系统都会优化支持kafka。
- 使用Scala和Java语言开发,设计上大量使用了批量和异步的思想,这种设计使得Kafka能做到超高的性能,尤其是异步收发性能,是三者中最好。
- 大概每秒可处理几十万条消息
劣势:
- 同步收发消息的响应时延比较高,当你的业务场景中,每秒消息数量没那么多时,kafka的时延反而会比较高。所以不太适合在线业务场景。
Kafka 官方文档:http://kafka.apache.org/documentation/
三、第二梯队的消息队列
这些产品之所有没那么流行,或多或少都有着比较明显的短板,不推荐使用,只是作简单介绍。
1、ActiveMQ
- 最老牌的开源消息队列,目前已进入老年期,社区不活跃。
- 功能或性能方面都与现代的消息队列存在明显的差距,它存在的意义仅限于兼容还在用的爷爷辈系统。
2、ZeroMQ
- 严格来说ZeroMQ并不能称之为一个消息队列,而是一个基于消息队列的多线程网络库。
- 如果你需要将消息队列的功能集成到你的系统进程中,可以考虑使用ZeroMQ。
3、Pulsar
- 一个新兴的开源消息队列产品,最早由Yahoo开发,目前处于成长期,流行度和成熟度相对没有那么高。
- 采用存储和计算分离的设计,有可能会引领未来消息队列的一个发展方向,建议持续关注这个项目。
四、总结:
选择的建议:
如果消息队列并不是将要构建系统的主角之一,对消息队列功能和性能都没有很高的要求,只需一个开箱即用易维护的产品,建议使用RabbitMQ。(有良好的运维界面,仅仅只是使用消息队列功能,用于异步和业务模块解耦,对性能要求不是很高。rabbitMQ能满足现阶段需求)
- 如果系统使用消息队列的场景是处理在线业务(在线业务指的是那种服务于web页面或者APP的服务,这种服务都需要很低的延迟,否则APP就会很卡,体验不好),比如在交易系统中用消息队列传递订单,那RocketMQ的低延迟和金融级的稳定性是你需要的。
- 如果需要处理海量的消息,想收集日志、监控信息或是前端埋点这类数据,或应用场景大量使用了大数据、流计算(做事后的统计分析)相关的开源产品,那kafka是最适合的。