一、选择消息队列产品的基本标准
在消息队列的技术选型上，并不存在说哪个消息队列就是“最好的”。常用的几个消息队列，每个产品都有自己的优势和劣势，需要根据现有系统的情况，选择最适合的那款产品。
技术产品的及格标准：
- 必须是开源产品：如果遇到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是最适合的。