消息队列MQ选型 - Kafka、RabbitMQ对比

谁借莪１个温暖的怀抱￠ 2021-11-05 18:58 393阅读 0赞

# 适应场景 #

异步处理，应用解耦，流量削锋和消息通讯

**RabbitMQ**：使用erlang开发的开源消息队列，通过erlang的actor模型实现了数据的稳定可靠传输，支持AMQP、XMQP、SMTP等多种协议，因此也比较重量级。由于采用broker代理架构，发送给客户端时，先在阻塞队列进行排队，rabbitMQ的单机吞吐量在万级。

**kafka**：由scala开发的高性能、跨语言、分布式消息队列，单机吞吐量可以达到10w级，消息延迟在毫秒级，kafka是完全分布式系统，broke、consume、produser都是原生自动支持分布式，依赖于zoopkeer做分布式协调，kafka支持一写多读，消息可以被多个服务端消费，消息有可能会重复，但是不会丢失。

# 对比 #

<table> 
 <thead> 
  <tr> 
   <th>feature</th> 
   <th>scenario</th> 
   <th>Kafka</th> 
   <th>RabbitMQ</th> 
   <th>备注</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>PUB-SUB 发布订阅模型</td> 
   <td>&nbsp;</td> 
   <td>√</td> 
   <td>√</td> 
  </tr> 
  <tr> 
   <td>推拉消费</td> 
   <td>Consumer消费消息的动作方式。</td> 
   <td>pull</td> 
   <td>push/pull</td> 
   <td>push更关注实时性。pull更关注消费者消费能力。</td> 
  </tr> 
  <tr> 
   <td>延迟消费</td> 
   <td>Producer产生一条消息后，并不希望立刻被消费掉。</td> 
   <td>X</td> 
   <td>√</td> 
   <td>高阶需求。</td> 
  </tr> 
  <tr> 
   <td>consumer group</td> 
   <td>同一条Message能同时被多个消费组消费，但同一group中，一条Message只会被一个consumer消费</td> 
   <td>√</td> 
   <td>√</td> 
   <td>KAFKA: 不需要在管理平台配置。 RabbitMQ：增加需要配置，涉及到内部数据冗余。</td> 
  </tr> 
  <tr> 
   <td>消息tag(filter)</td> 
   <td>以过滤出tag为keyword的message</td> 
   <td>X</td> 
   <td>X</td> 
  </tr> 
  <tr> 
   <td>消息回溯</td> 
   <td>从历史中的某个位置重新拉取消息</td> 
   <td>X</td> 
   <td>X</td> 
   <td>只对拉模式，推模式不考虑回溯，支持时间维度offset</td> 
  </tr> 
  <tr> 
   <td>事务性</td> 
   <td>mq内部逻辑，消息状态是否一致</td> 
   <td>X</td> 
   <td>√</td> 
   <td>和消息中间件内部实现相关。</td> 
  </tr> 
  <tr> 
   <td>优先级</td> 
   <td>消息优先级，consumer优先消费高优先级消息。</td> 
   <td>X</td> 
   <td>√</td> 
  </tr> 
  <tr> 
   <td>染色</td> 
   <td>追踪消息在mq中的具体耗时</td> 
   <td>X</td> 
   <td>X</td> 
  </tr> 
  <tr> 
   <td>本地读优化</td> 
   <td>Producer\Consumer 不在同一机房。MQ搭建在P端，C端会存在跨机房访问的问题。</td> 
   <td>X</td> 
   <td>X</td> 
   <td>使用数据同步工具，将P所在机房数据同步到C所在机房的集群。</td> 
  </tr> 
  <tr> 
   <td>doubt message(消息追踪)</td> 
   <td>跨公司，异构系统间，消息状态追踪。</td> 
   <td>X</td> 
   <td>X</td> 
  </tr> 
  <tr> 
   <td>消息积压</td> 
   <td>没有被消费的消息在MQ中堆积</td> 
   <td>√</td> 
   <td>√</td> 
   <td>支持程度的区别，不同mq会存在不同。</td> 
  </tr> 
  <tr> 
   <td>负载均衡</td> 
   <td>1：防止单点 2：C端压力LB在MQ各节点上。</td> 
   <td>√</td> 
   <td>√</td> 
   <td>RMQ：多集群做负载</td> 
  </tr> 
  <tr> 
   <td>支持的消息大小</td> 
   <td>每条消息的大小</td> 
   <td>无限制</td> 
   <td>无限制</td> 
   <td>需要对消息大小做限制，降低系统不确定性。</td> 
  </tr> 
  <tr> 
   <td>定期回收消息</td> 
   <td>mq中的消息一旦被消费后，可以被删除，空间回收。</td> 
   <td>√</td> 
   <td>√</td> 
  </tr> 
  <tr> 
   <td>消费语义</td> 
   <td>方式分别为：1、最多消费一次 2、最少消费一次3、仅消费一次</td> 
   <td>2</td> 
   <td>2</td> 
   <td>业务方消费端做幂等</td> 
  </tr> 
  <tr> 
   <td>对全局序支持</td> 
   <td>消息在全局保持时序一致</td> 
   <td>X</td> 
   <td>X</td> 
   <td>设计复杂度原因，不考虑支持</td> 
  </tr> 
 </tbody> 
</table>

> 备注：  
> “√” 表示目前系统已主持  
> “X” 表示系统不考虑支持该特性

链接：[https://www.jianshu.com/p/20f9be3c45d3][https_www.jianshu.com_p_20f9be3c45d3]

[https_www.jianshu.com_p_20f9be3c45d3]: https://www.jianshu.com/p/20f9be3c45d3