如何选择消息队列

选择消息队列产品的基本标准

首先，必须是开源的产品，开源意味着，如果有一天你使用的消息队列遇到了一个影响你系统业务的BUG,你至少有机会通过修改源代码来修复或规避这个Bug。

其次，这个产品必须是近年来比较流行并且有一定社区活跃度的产品，流行的好处是，只要使用场景不太冷门，遇到Bug的几率会非常低。使用过程中的问题，网上基本都会有解决方案。

有一个优势就是，流行的产品与周边生态系统会有一个比较好的集成和兼容。

最后，作为一款及格的消息队列产品，必须具备的几个特性包括：

• 消息的可靠传递：确保不丢消息；
• Cluster：支持集群，确保不会因为某个节点宕机导致服务不可用，当然也不能丢消息。
• 性能：具备足够好的性能，能满足绝大多数场景的性能要求。

可供选择的消息队列产品

1. RabbitMQ

Erlang 语言编写的,支持 AMQP 协议，轻量级、迅捷。宣传口号：Messaging that just works，“开箱即用的消息队列”

一个比较有特色的功能是支持非常灵活的路由配置，和其他消息队列不同的是，它在生产者（Producer）和队列（Queue）之间增加了一个 Exchange 模块，这个 Exchange 模块的作用和交换机也非常相似，

根据配置的路由规则将生产者发出的消息分发到不同的队列中。路由的规则也非常灵活，甚至你可以自己来实现路由规则。基于这个 Exchange，可以产生很多的玩儿法，如果你正好需要这个功能，RabbitMQ 是个不错的选择。

RabbitMQ 的客户端支持的编程语言大概是所有消息队列中最多的。

接下来说下 RabbitMQ 的几个问题。

第一个问题是，RabbitMQ 对消息堆积的支持并不好，当大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降。

第二个问题是，RabbitMQ 的性能是我们介绍的这几个消息队列中最差的，它大概每秒钟可以处理几万到十几万条消息。

最后一个问题是 RabbitMQ 使用的编程语言 Erlang，这个编程语言是非常小众的语言而且不易学习。

2. RocketMQ

RocketMQ 是阿里巴巴在 2012 年开源的消息队列产品，后来捐赠给 Apache 软件基金会，成为 Apache 的顶级项目。

RocketMQ 对在线业务的响应时延做了很多的优化，大多数情况下可以做到毫秒级的响应，RocketMQ 的性能比 RabbitMQ 要高一个数量级，每秒钟大概能处理几十万条消息。

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

3. Kafka

Kafka 最早是由 LinkedIn 开发，目前也是Apache 的顶级项目。当下的 Kafka 已经发展为一个非常成熟的消息队列产品，无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求。

Kafka 与周边生态系统的兼容性是最好的没有之一，尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持 Kafka。

Kafka 使用 Scala 和 Java 语言开发，设计上大量使用了批量和异步的思想，这种设计使得 Kafka 能做到超高的性能。但是因为这种异步批量的设计，他的同步收发消息的响应时延比较高，因为

很多地方都会使用这种“先攒一波再一起处理”的设计，所以，Kafka 不太适合在线业务场景。Kafka 不太适合在线业务场景。

Kafka 的性能，尤其是异步收发的性能，是三者中最好的，但与 RocketMQ 并没有量级上的差异，大约每秒钟可以处理几十万条消息。

总结

只需要一个开箱即用易于维护的产品，我建议你使用 RabbitMQ。

如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那 RocketMQ 的延迟和金融级的稳定性是你需要的。

如果你需要处理海量的消息，像收集日志、控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那 Kafka 是最适合你的消息队列。