消息队列的选择

选择的建议：

如果消息队列并不是将要构建系统的主角之一，对消息队列功能和性能都没有很高的要求，只需一个开箱即用易维护的产品，建议使用RabbitMQ。(有良好的运维界面，仅仅只是使用消息队列功能，用于异步和业务模块解耦，对性能要求不是很高。rabbitMQ能满足现阶段需求)

• 如果系统使用消息队列的场景是处理在线业务(在线业务指的是那种服务于web页面或者APP的服务，这种服务都需要很低的延迟，否则APP就会很卡，体验不好)，比如在交易系统中用消息队列传递订单，那RocketMQ的低延迟和金融级的稳定性是你需要的。
• 如果需要处理海量的消息，想收集日志、监控信息或是前端埋点这类数据，或应用场景大量使用了大数据、流计算(做事后的统计分析)相关的开源产品，那kafka是最适合的。

常见的消息队列列举

产品	功能特点	性能QPS
RabbitMQ	介绍： 使用Erlang语言编写，最早是为电信行业系统之间的可靠通讯性设计的，也是少数几个支持AMQP协议的消息队列。 轻量级、迅速，开箱即用，非常容易部署和使用。 有一个特色的功能是支持非常灵活的路由配置。它在生产者和队列之间增加了一个Exchange模块，可以理解为交换机，根据配置的路由规则将生产者发出的消息分发到不同的队列中。 客户端支持的编程语言是所有消息队列中最多的。 劣势： 对消息堆积的支持并不好。在它的设计理念中，消息队列是一个管道，大量的消息积压不是正常的情况，应当尽量避免。当大量消息积压时，会导致性能急剧下降。 RabbitMQ的性能是介绍的几个消息队列中最差的，它大概每秒可以处理几万到几十万条消息，这个性能也足够支撑绝大多数场景。不过，如果你的应用对消息队列的性能要求非常高，那就不要选择RabbitMQ。 小众的编程语言Erlang。如果想基于RabbitMQ做一些扩展和二次开发，建议你慎重考虑可持续维护的问题。 RabbitMQ 官方文档：https://www.rabbitmq.com/documentation.html	几万到几十万
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/	几十万
Kafka	介绍： 最早是由LinkedIn开发，目前也是Apache的顶级项目。最初的设计目的是用于处理海量的日志。 与周边生态系统的兼容性是最好的，尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优化支持kafka。 使用Scala和Java语言开发，设计上大量使用了批量和异步的思想，这种设计使得Kafka能做到超高的性能，尤其是异步收发性能，是三者中最好。 大概每秒可处理几十万条消息 劣势： 同步收发消息的响应时延比较高，当你的业务场景中，每秒消息数量没那么多时，kafka的时延反而会比较高。所以不太适合在线业务场景。 Kafka 官方文档：http://kafka.apache.org/documentation/

不建议使用的：

产品	功能特点	性能（QPS）
ActiveMQ	最老牌的开源消息队列，目前已进入老年期，社区不活跃。 功能或性能方面都与现代的消息队列存在明显的差距，它存在的意义仅限于兼容还在用的爷爷辈系统。
ZeroMQ	严格来说ZeroMQ并不能称之为一个消息队列，而是一个基于消息队列的多线程网络库。 如果你需要将消息队列的功能集成到你的系统进程中，可以考虑使用ZeroMQ。
Pulsar	一个新兴的开源消息队列产品，最早由Yahoo开发，目前处于成长期，流行度和成熟度相对没有那么高。 采用存储和计算分离的设计，有可能会引领未来消息队列的一个发展方向，建议持续关注这个项目。