Kafka，RabbitMQ，RocketMQ三种消息服务的对比

在前文“为什么要使用消息队列？【3个常见的场景：解耦，异步，削峰填谷】”中，介绍了消息队列的一系列优点和可以应用到的3个常见的场景。那么消息队列在带来一系列便利和高效的同时，会不会同时带来一些限制呢？在了解了优点和限制之后，市面上这些主流的消息队列中间件又都有什么区别呢？

消息服务的限制

首先，我们来看消息队列的限制都有哪些。大体也分为三类：系统可用性，系统复杂性，数据一致性。

系统可用性

就和前文里提到的那样，原本系统里服务A直接调用服务B,C,D的接口即可，没啥问题。我们加了个消息队列进去，一旦它崩溃了，整套系统都会崩溃。所以如何保障消息队列的高可用是非常关键的。

系统复杂性

系统多了个消息队列，服务A是轻松了，直接把消息传给消息队列就可以了。那如何保障消息队列里的消息传递的顺序呢？如何保障消息不会被重复消费呢？万一消息丢失了如何处理呢？等等一堆问题，让系统复杂性也变高了。

数据一致性

服务A处理完数据并把消息发给了消息队列，就直接返回成功给客户端，用户就会以为他的请求成功了。单问题是，服务B,C,D可能只有服务B，C成功处理了消息，服务D失败了，导致A,B,C和D的数据不一致了，这时候怎么办呢？

多句嘴：有一个办法是，把所有服务（A,B,C,D）都算成一个事务里，要成功大家一起成功，要失败大家一起失败。这样就是时间会有所延长：比如原先只要服务A处理的时间5ms+发送消息给消息队列5ms = 10ms时间，现在因为大家都是一个事务，就需要服务A处理的时间5ms+发送消息给消息队列5ms+服务B/C/D里消耗最长的一个时间500ms = 510ms。但是这可以保证返回给客户端的成功是真的全部成功了。

三个服务的对比

目前在市面上主流的消息队列中间件主要有，Kafka、RabbitMQ、RocketMQ 等这3种。其实开发人员最早用的是ActiveMQ，但现在大家用的不多了，社区不活跃（生态很重要啊），加上没经过大规模吞吐量场景的验证，也就没什么人在提了。

这3者华为云都有对应的DMS服务在提供，大家感兴趣可以去华为云官网看看：

那这三个开源版本的消息队列中间件都有什么区别呢？

• RabbitMQ:
  单机吞吐量万级；延迟很低，性能极好，微妙级（基于ErLang，一种通用的面向并发的编程语言开发）；基于主从架构实现高可用性；数据基本不会丢失。
• RocketMQ:
  单机吞吐量十万级，topic数量对单机吞吐量影响较小（可达到几百/几千的级别，吞吐量会有较小幅度的下降）；延迟达到毫秒级；分布式架构，可用性更高，扩展性更好；经过参数优化配置，可以做到 0 丢失；
• Kafka：
  单机吞吐量十万级，topic数量对单机吞吐量影响大（可达到几十/几百的级别，吞吐量会有大幅度的下降，需要更多机器资源）；延迟达到毫秒级；分布式架构（1个数据多个副本），可用性更高；经过参数优化配置，可以做到 0 丢失。

从上列表，我们也可以看出：

• RabbitMQ延迟低性能高，这得益于ErLang，但同时因为这款语言小众的特性，阻止了研发人员去深入研究它（绝大部分研发人员才不会因为一款中间件去学习一门语言呢），导致研发团队会觉得这款组件不可控；不过又好在它的社区还是很活跃的。
• RocketMQ起源于阿里巴巴，topic数量对单机吞吐量影响较小，但是社区活跃度和另外两者相比差很多。
• Kafka则非常经典了，碰到大数据类的系统来进行实时数据计算、日志采集场景，业内标准就是用它。