关于MQ选型

选型标准

1.1 开源（白嫖）

方便可以修改源代码，而非一味地等待软件提供商猴年马月发布的下个版本解决。在知识产权下，使用开源的才可商用。

1.2 生态（大家都玩）

主要你的使用场景不冷门，你遇到bug的概率非常低，因为大部分你可能遇到的，其他人早就遇到并且修复。使用过程中遇到的一些问题，也容易在网上搜索到类似的，然后找到解决方案。和其他框架也能无缝对接。

1.3 确保消息可靠传递

1.4 cluster

高可用性

1.5 性能

具备足够好的性能，能满足绝大多数场景的性能要求。

RabbitMQ
优点
Erlang语言编写，最早是为电信行业系统可靠通信设计，是支持AMQP协议的消息队列之一。相当轻量级的消息队列，非常容易部署和使用。号称世上使用最广泛的开源消息队列。

支持非常灵活的路由配置
和其他消息队列不同，它在生产者（Producer）和队列（Queue）之间增加了一个Exchange模块。

作用和交换机相似，根据配置的路由规则将生产者发出的消息分发到不同队列。

路由规则也非常灵活，甚至你可以自己来实现路由规则。如果你正好需要该功能，RabbitMQ是个不错选择。

支持的客户端语言
所有消息队列中最多的

缺点
消息堆积的支持不好

设计理念：消息队列是一个管道，大量的消息积压是一种不正常的情况，应当尽量避免。

当大量消息积压的时候，RabbitMQ的性能急剧下降。

性能
介绍的这几个消息队列中最差的，根据官方给出的测试数据综合我们日常使用的经验，依据硬件配置的不同，它大概可以处理几w~十几w条/s。也足够支撑绝大多数应用场景了，不过，如果你的应用对消息队列的性能要求非常高，那不要选RabbitMQ。

Erlang
小众语言，学习曲线非常陡峭。如果想做扩展和二次开发，慎重考虑维护问题。

RocketMQ

阿里巴巴在2012年开源的消息队列产品，后来捐赠给 Apache 软件基金会，2017正式毕业，成为Apache的顶级项目。阿里内部也是使用RocketMQ作为支撑其业务的消息队列，经历过多次“双十一”考验，它的性能、稳定性和可靠性都是值得信赖的。作为优秀的国产消息队列，近年来越来越多的被国内众多大厂使用。

RocketMQ有着不错的性能，稳定性和可靠性，具备一个现代的消息队列应该有的几乎全部功能和特性，且还在持续成长。

优点

非常活跃的中文社区
大多数问题你都可以找到中文的答案，也许会成为你选择它的一个原因。

RocketMQ使用Java语言开发
贡献者大多数都是中国人，源代码相对也比较容易读懂，很容易对RocketMQ进行扩展或者二次开发。

RocketMQ对在线业务的响应时延做了很多的优化
大多数情况下可以做到ms级响应，如果你的应用场景很在意响应时延，那应该选择使用RocketMQ。

RocketMQ是怎么做到低延时的？
主要是设计上的选择问题，Kafka中到处都是“批量和异步”设计，它更关注的是整体的吞吐量，而RocketMQ的设计选择更多的是尽量及时处理请求。
比如发消息，同样是用户调用了send()方法，RockMQ它会直接把这个消息发出去，而Kafka会把这个消息放到本地缓存里面，然后择机异步批量发送。
所以，RocketMQ它的时延更小一些，而Kafka的吞吐量更高。

RocketMQ的性能比RabbitMQ要高一个数量级
大概处理几十w条/s。

缺点
作为国产的消息队列，相比国外的比较流行的同类产品，在国际上还没有那么流行，与周边生态系统的集成和兼容程度要略逊一筹。

Kafka

最早由LinkedIn开发，目前也是Apache顶级项目。最初的设计目的是用于处理海量的日志。

在早期的版本中，为了获得极致性能，在设计方面做了很多的牺牲，比如：

不保证消息的可靠性
可能会丢失消息
不支持集群
功能上较简陋

这些牺牲对于处理海量日志这个特定的场景都是可以接受的。这个时期的Kafka甚至不能称之为一个合格的消息队列。

但作为后起之秀。随后Kafka逐步补齐这些短板，你在网上搜到的很多消息队列的对比文章还在说Kafka不可靠，其实这种说法早已过时。当下的Kafka已经发展为一个非常成熟的消息队列产品，无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求（快手就在使用其作为消息队列）。

优点

Kafka与周边生态系统的兼容性最好
尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持Kafka。
Kafka使用Scala和Java语言开发
设计上大量使用了批量和异步的思想，这种设计使得Kafka能做到超高的性能。可维护性也好，会 java 即可。
Kafka的性能
尤其是异步收发的性能，三者中最好，但与RocketMQ并无量级差异，大约每秒钟可处理几十万条消息。

在有足够的客户端并发进行异步批量发送，并且开启压缩的情况下，Kafka的极限处理能力可以超过每秒2000万条消息。

缺点

但Kafka这种异步批量的设计带来的问题是，它的同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka并不会立即发送出去，而是要等一会儿攒一批再发送，在它的Broker中，很多地方都会使用这种“先攒一波再一起处理”的设计。

当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka的时延反而会比较高。所以，Kafka不太适合在线业务场景。

其它MQ

ActiveMQ
最老牌的开源消息队列，十年前唯一可供选择的开源消息队列，目前已进入老年期，社区不活跃。无论是功能还是性能方面，ActiveMQ都与现代的消息队列存在明显的差距，它存在的意义仅限于兼容那些还在用的爷辈儿系统。
ZeroMQ
严格来说ZeroMQ并不能称之为一个消息队列，而是一个基于消息队列的多线程网络库，如果你的需求是将消息队列的功能集成到你的系统进程中，可以考虑使用ZeroMQ。
Pulsar
Pulsar是一个新兴的开源消息队列产品，最早是由Yahoo开发，目前处于成长期，流行度和成熟度相对没有那么高。与其他消息队列最大的不同是，Pulsar采用存储和计算分离的设计，我个人非常喜欢这种设计，它有可能会引领未来消息队列的一个发展方向，建议你持续关注这个项目。
目前已经在使用Pulsar的公司已经不少了,国内的话有下面几家:
涂鸦智能、腾讯计费系统、智联招聘、甜橙金融、EMQX。

kafka、activemq、rabbitmq、rocketmq对比

选型总结

最早大家都用ActiveMQ，但是现在用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，算了吧，不推荐
后来大家开始用RabbitMQ，但erlang语言阻止了大量的java工程师去深入研究和掌控他，几乎处于不可控，但是开源的，比较稳定支持，活跃度也高。如果消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，建议RabbitMQ。
如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那RocketMQ的低延迟和金融级的稳定性是你需要的。
如果需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那Kafka是最适合。