RabbitMQ，RocketMQ和Kafka三种消息队列的对比

前言

正如我们通常所说的，没有最好的技术，只有最合适的技术。同样，还有一个说法“没有银弹”，银弹是指能轻松杀死狼人，用白银做的子弹。在软件工程中，不存在像“银弹”这样可以解决一切问题的设计，架构或软件，每个软件系统，都是独一无二的，不可能用一套方法去解决所有的问题。

在项目上对消息队列的选型也是如此，没有说哪个消息队列就是最好的。常用的消息队列中，每一个产品都有自己的优劣，要根据现有的项目情况，去选择最适合的消息队列。

虽然每种消息队列在功能和特性上有所差异，但是我们在选择消息队列时要保证所选择的消息队列能满足一些基本标准。

必须是开源的产品。开源意味着，如果有一天你使用的消息队列遇到了一个影响你系统业务的 Bug，你至少还有机会通过修改源代码来迅速修复或规避这个 Bug，解决你的系统火烧眉毛的问题，而不是束手无策地等待开发者不一定什么时候发布的下一个版本来解决。
近年来比较流行并且具有一定的社区活跃度。意味着只要你的使用场景不太冷门，就能轻松找到解决方法。因为大部分你可能遇到的bug，其他人早就遇到并且修复了，用的过程中很容易在网上搜到类似的问题，然后很快就能找到解决方案。
还有一个优势就是流行的产品与周边生态系统会有一个比较好的集成和兼容。

必须具备的特性：

由Erlang语言编写的，支持AMQP协议，是一个相当轻量级的消息队列，非常容易部署和使用。

优势：

支持非常灵活的路由配置。和其他消息队列不同的是，它在生产者和队列之间增加了一个Exchange模块，可以理解为交换机。这个Exchange模块的作用和交换机也非常类似，根据配置的路由规则将生产者发出的消息分发到不同的队列中。路由的规则也非常灵活，甚至可以自己来实现路由规则。
RabbitMQ的客户端支持的编程语言大概是所有消息队列中最多的，如果你的系统是用某种冷门语言开发的，多数情况下能找到对应的RabbitMQ客户端。

存在问题：

RabbitMQ对消息堆积的支持并不好，在它的设计理念里，消息队列是一个管道，大量的消息积压是一种不正常的情况，应该尽量去避免。当有大量消息积压的时候，会导致RabbitMQ 的性能急剧下降。
性能低，依据硬件配置的不同，它大概每秒可以处理几万到十几万条消息。
由Erlang语言编写，学习成本高。如果想要对RabbitMQ做一些扩展和二次开发，可持续维护差

RockectMQ有着不错的性能，稳定性和可靠性，具备一个现代的消息队列应该有的几乎全部功能和特性。

优势：

存在问题：

Kafka最初的设计目的是用于处理海量的日志。随着不断的发展，目前也是一个非常成熟的消息队列，无论在数据可靠性，稳定性和功能特性等方面都可以满足绝大多数场景的需求。

优势：

兼容性好。Kafka与周边生态环境的兼容性是最好的没有之一，尤其是在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持Kafka。
性能高。Kafka由java和Scala语言开发，在设计上大量使用了批量和异步的思想，使得Kafka能做到超高的性能。Kafka的性能，尤其是异步收发的性能是三者中最好的。它大约每秒能处理几十万条消息。对 Kafka 进行过压测，在有足够的客户端并发进行异步批量发送，并且开启压缩的情况下，Kafka 的极限处理能力可以超过每秒 2000 万条消息。

存在问题：

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

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

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

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

温娉哲

原创文章 209 获赞 264 访问量 11万+