Kafka、RabbitMQ、RocketMQ比较

矫情吗；* 2022-09-04 05:39 136阅读 0赞

<table> 
 <thead> 
  <tr> 
   <th>特性</th> 
   <th>ActiveMQ</th> 
   <th>RabbitMQ</th> 
   <th>RocketMQ</th> 
   <th>kafka</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>开发语⾔</td> 
   <td>java</td> 
   <td>erlang</td> 
   <td>java</td> 
   <td>scala</td> 
  </tr> 
  <tr> 
   <td>单机吞吐量</td> 
   <td>万级</td> 
   <td>万级</td> 
   <td>10万级</td> 
   <td>10万级</td> 
  </tr> 
  <tr> 
   <td>时效性</td> 
   <td>ms级</td> 
   <td>us级</td> 
   <td>ms级</td> 
   <td>ms级</td> 
  </tr> 
  <tr> 
   <td>可⽤用性</td> 
   <td>高（主从架构）</td> 
   <td>高（主从架构）</td> 
   <td>非常高（分布式架构）</td> 
   <td>非常高（分布式架构）</td> 
  </tr> 
  <tr> 
   <td>消息可靠性</td> 
   <td>有较低的概率丢失数据</td> 
   <td></td> 
   <td>经过参数优化配置，消息可以做到0丢失</td> 
   <td>经过参数优化配置，消息可以做到0丢失</td> 
  </tr> 
  <tr> 
   <td>功能特性</td> 
   <td>成熟的产品，在很多公司得到应用；有较多的⽂档；各种协议支持较好</td> 
   <td>基于erlang开发，所以并发能⼒很强，性能极其 好，延时很低;吞吐量会低一些，这是因为他做的实现机制比较重。管理界⾯面较丰富;</td> 
   <td>MQ功能⽐比较完备，扩展 性佳</td> 
   <td>只支持主要的MQ功能，像⼀些消息查询，消息回溯等功能没有提供，毕竟是为⼤数据准备的，在⼤数据领域应⽤广，kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略</td> 
  </tr> 
 </tbody> 
</table>

（1）Kafka的优势和劣势  
首先Kafka的吞吐量几乎是行业里最优秀的，在常规的机器配置下，一台机器可以达到每秒十几万的QPS，相当的强悍。  
Kafka性能也很高，基本上发送消息给Kafka都是毫秒级的性能。可用性也很高，Kafka是可以支持集群部署的，其中部分机器宕机是可以继续运行的。  
但是Kafka比较为人诟病的一点，似乎是丢数据方面的问题，因为Kafka收到消息之后会写入一个磁盘缓冲区里，并没有直接落地到物理磁盘上去，所以要是机器本身故障了，可能会导致磁盘缓冲区里的数据丢失。  
而且Kafka另外一个比较大的缺点，就是功能非常的单一，主要是支持发送消息给他，然后从里面消费消息，其他就没有什么额外的高级功能了。所以基于Kafka有限的功能，可能适用的场景并不是很多。  
因此综上所述，以及查阅了Kafka技术在各大公司里的使用，基本行业里的一个标准，是把Kafka用在用户行为日志的采集和传输上，比如大数据团队要收集APP上用户的一些行为日志，这种日志就是用Kafka来收集和传输的。  
因为那种日志适当丢失数据是没有关系的，而且一般量特别大，要求吞吐量要高，一般就是收发消息，不需要太多的高级功能，所以Kafka是非常适合这种场景的。

（2）RabbitMQ的优势和历史  
再说RabbitMQ，在RocketMQ出现之前，国内大部分公司都从ActiveMQ切换到RabbitMQ来使用，包括很多一线互联网大厂，而且直到现在都有很多中小型公司在使用RabbitMQ。  
RabbitMQ的优势在于可以保证数据不丢失，也能保证高可用性，即集群部署的时候部分机器宕机可以继续运行，然后支持部分高级功能，比如说死信队列，消息重试之类的，这些是他的优点。  
但是他也有一些缺点，最为人诟病的，就是RabbitMQ的吞吐量是比较低的，一般就是每秒几万的级别，所以如果遇到特别特别高并发的情况下，支撑起来是有点困难的。  
而且他进行集群扩展的时候（也就是加机器部署），还比较麻烦。另外还有一个较为致命的缺陷，就是他的开发语言是erlang，国内很少有精通erlang语言的工程师，因此也没办法去阅读他的源代码，甚至修改他的源代码。  
所以现在行业里的一个情况是，很多BAT等一线互联网大厂都切换到使用更加优秀的RocketMQ了，但是很多中小型公司觉得RabbitMQ基本可以满足自己的需求还在继续使用中，因为中小型公司并不需要特别高的吞吐量，RabbitMQ已经足以满足他们的需求了，而且也不需要部署特别大规模的集群，也没必要去阅读和修改RabbitMQ的源码。

（3）RocketMQ的优势和劣势  
RocketMQ是阿里开源的消息中间件，久经沙场，非常的靠谱。他几乎同时解决了Kafka和RabbitMQ的缺陷。  
RocketMQ的吞吐量也同样很高，单机可以达到10万QPS以上，而且可以保证高可用性，性能很高，而且支持通过配置保证数据绝对不丢失，可以部署大规模的集群，还支持各种高级的功能，比如说延迟消息、事务消息、消息回溯、死信队列、消息积压，等等。  
而且RocketMQ是基于Java开发的，符合国内大多数公司的技术栈，很容易就可以阅读他的源码，甚至是修改他的源码。  
所以现在国内很多一线互联网大厂都切换为使用RocketMQ了，他们需要RocketMQ的高吞吐量，大规模集群部署能力，以及各种高阶的功能去支撑自己的各种业务场景，同时还可以根据自己的需求定制修改RocketMQ的源码。  
RocketMQ是非常适合用在Java业务系统架构中的，因为他很高的性能表现，还有他的高阶功能的支持，可以让我们解决各种业务问题。  
当然，RocketMQ也有一点美中不足的地方，就是经过我的调查发现，RocketMQ的官方文档相对简单一些，但是Kafka和RabbitMQ的官方文档就非常的全面和详细，这可能是RocketMQ目前唯一的缺点。

（4）活跃的社区和广泛的运用  
最后一点，基本上Kafka、RabbitMQ和RocketMQ的社区都还算活跃，更新频率都还可以，而且基本运用都非常的广泛。  
尤其是Kafka和RabbitMQ，目前Kafka几乎是国内大数据领域日志采集传输的标准，RabbitMQ在各种中小公司里运用极为广泛，RocketMQ也是开始在一些大公司和其他公司里快速推行中。