这是我参与11月更文挑战的第7天，活动详情查看：2021最后一次更文挑战

现如今，市场上有很多款消息队列供我们选择，像kafka,RabbitMq,RocketMq...,那我们该如何选择和项目适配的消息队列呢？

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

1.消息的可靠传递:确保不丢消息;

2.支持集群，确保不会因为某个节点宕机导致服务不可用，当然也不能丢消息;

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

一.RabbitMq

RabbitMQ 是一个相当轻量级的消息队列，非常容易部署和使用。

RabbitMQ具有一个比较有特色的功能是支持非常灵活的路由配置，和其他消息队列不同的是，它在生产者(Producer)和队列(Queue)之间增加了一个Exchange 模块，你可以理解为交换机。

这个 Exchange 模块的作用和交换机也非常相似，根据配置的路由规则将生产者发出的消息分发到不同的队列中。路由的规则也非常灵活，甚至你可以自己来实现路由规则。

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

第一个问题是，RabbitMQ 对消息堆积的支持并不好，在它的设计理念里面，消息队列是一个管道，大量的消息积压是一种不正常的情况，应当尽量去避免。当大量消息积压的时候，会导致RabbitMQ的性能急剧下降。

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

二.RoctetMq

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

RocketMQ 有非常活跃的中文社区，大多数问题你都可以找到中文的答案，也许会成为你选择它的一个原因。另外，RocketMQ 使用 Java 语言开发，它的贡献者大多数都是中国人，源代码相对也比较容易读懂，你很容易对 RocketMQ 进行扩展或者二次开发。

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

RocketMQ的性能比RabbitMQ 要高一个数量级，每秒钟大概能处理几十万条消息。

三.Kafka

Kafka 最初的设计目的是用于处理海量的日志。

在早期的版本中，为了获得极致的性能，在设计方面做了很多的牺牲，比如不保证消息的可靠性，可能会丢失消息，也不支持集群，功能上也比较简陋，但是当下的Kafka 已经发展为一个非常成熟的消息队列产品，无论在数据可靠性、稳定性和功能特性等 方面都可以满足绝大多数场景的需求。

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

Kafka 使用 Scala 和 Java 语言开发，设计上大量使用了批量和异步的思想，这种设计使得 Kafka 能做到超高的性能。Kafka 的性能，尤其是异步收发的性能，是三者中最好的，但与RocketMQ并没有量级上的差异，大约每秒钟可以处理几十万条消息。Kafka 的极限处理能力可以超过每秒2000万条消息。

但是 Kafka 这种异步批量的设计带来的问题是，它的同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka 并不会立即发送出去，而是要等一会儿攒一批再发 送，在它的Broker中，很多地方都会使用这种“先攒一波再一起处理”的设计。当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反而会比较高。所以，Kafka 不太适合在线业务场景。

总结

1.如果说，消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，我建议你使用 RabbitMQ。

2.如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，我建议你使用 RocketMQ。

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