RabbitMQ与Kafka选型对比

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

背景

本公司是.Net项目，在.Net可选的MQ比较少，主要Kafka和RabbitMQ，RabbitMQ我也是使用多年了，最近的Kafka广告与流行度打得使我也是无法无视，因此也是花了点时间收集了资料做了些对比。

此外有个小插曲，当我形成了文档让老板兼CTO对比决策后，他打算上阿里云买MQ服务。我当时给他开了个玩笑：您这价钱把我请回来，而且公司还有运维，其实完全可以自己维护，要不我来负责，你把这每个月的MQ费用给我加工资得了。当我下楼买了支维他柠檬茶后，他决定由我们自己搭建RabbitMQ。这个决定跟我的想法差不多，原因主要两点：运维起来方便，吞吐没有特别高。

RabbitMQ模型

• Exchange在声明时会绑定Queue和Binding Key，当Exchange收到消息会根据消息的
• Routing Key与Exchange Type、Binding Key进行匹配，最后会路由到相关的队列当中。
  • Fanout，将消息发送到与该交换器所绑定的所有队列中，与Routing Key、Bind Key无关，这就是广播模式。
  • Topic，通过对消息的Routing Key和Exchange、Queue进行匹配，将消息路由给一个或多个队列，以此来达到发布/订阅模式。
  • Direct，把消息路由到哪些Bind Key和Routing Key完全匹配的队列中。
  • Headers，不依赖与路由键的匹配规则，基本用不上。
• 消费者会直接订阅Queue里的消息进行消费，多个消费者订阅同个Queue会形成消息竞争状态，以此达到负载均衡作用。

Kafka模型

• Kafka与RabbitMQ比没有Exchange的概念，生产者直接发消息Topic（队列）。
• Kafka的订阅者是通过消费组（Consumer Group）来体现的，每个消费组都可以重复消费Topic一份完整的消息，不同消费组之间消费进度彼此不受影响。例如Message1能被Consumer Group 1和Consumer Group2里的消费者都消费一次。
• 消费组中包含多个消费者，同个Group的消费者之间是竞争消费的关系。例如Message2只能够被Consumer Group里某一个Consumer只消费一次。
• Kafka具有消息存储的功能，消息被消费后不会被立即删除，因为需要被不同的Consumer Group多次消费同个消息，因此会在Topic维护一个Consumer Offset，每消费成功Offset自增1.

功能对比

对比描述

共同点

RabbitMQ与Kafka都有很好的客户端语言支持、安全机制与生态支持。

性能

Kafka的诞生的是处理高并发日志的，吞吐量比较高，每秒请求数达到数十万量级，而RabbitMQ每秒请求数则为万级别，有测试报告指出Kafka是RabbitMQ的10倍以上性能。

运维便捷

RabbitMQ相对比较方便，可以使用yum或者docker安装，自带Web管理UI，没有额外的依赖，除了需要做镜像队列外需要引入HAproxy。

Kafka则需要依赖Zookeeper，也没有自带的管理工具，可以使用第三方的Kafka Eagle代替，Kafka Manager过于难用，另外Kafka没有yum安装，docker镜像也是社区人员自己建的。

有序性

RabbitMQ理论上是全局有序性的，但是由于【发后既忘】+【自动确认】机制的原因，如果在同个队列的多个消费者做相同的业务处理时，他们的各自的执行任务无法保证有序完成。如果确保100%有序可以使用【非自动确认】，但会影响消费性能。

Kafka支持分区有序性，如果对有序性有严格要求可以设置单个Partition，可是单个Partition并发性比较低，因此在多个Partition情况下可以根据业务指定key把相关的消息路由到同一个Partition，例如相同UserId行为信息可以到Partition 1进行处理。

时效性

Kafka基本上无论在客户端还是服务端都是以【异步批量】的机制进行处理，通俗的讲就是先攒起来一堆消息，到了某个阀值再发送，也会导致一些消息可靠性与消息有时效上的问题，当然可以通过各种配置策略进行解决。

消息回溯

Kafka在消费完了消息后不会立即删除，只会修改offset，如果之前部分业务消费失败了可以重新设置offset进行重新消费。

RabbitMQ则是[发后既忘]的机制，一但消费者确认消息则删除，但是可以通过死信进行补偿消费。此外RabbitMQ在队列消息堆积多的情况下性能表现不佳，所以尽可能的及时消费消息。

特色功能

RabbitMQ具有死信的功能，可以通过死信形成重复消费与延时发送。

Kafka具有流处理功能，可以收集用户的行为日志进行存储与分析。

Kafka为什么快？

关键核心技术点：

• 异步批量处理
• 磁盘顺序读写
• 操作系统PageCache缓存数据
• 零拷贝加速消费

Kafka的诞生就是为了高并发日志处理的，那么在他整个机制里使用了很多批量、异步、缓存。例如生产者客户端，他会积累一定量（条数、大小）的消息，再批量的发给kafka broker，如果在这段时间客户端服务挂了，就等于消息丢失了。当broker接受到了消息后，还有一堆骚操作-异步刷盘，也就是生产者发送给broker之后他是记录在缓存的，每隔一段时间才会持久化到磁盘，假如这段真空期broker挂了，消息也是丢了。

Kafka是否消息不可靠？

Kafka快是因为牺牲了消息可靠换取回来的性能，在最早期版本的确没提供消息可靠的策略，经过多个版本迭代后的功能完善，已经不存在这种旧观念。那么可靠的关键点有以下：

生产者

设置ack：

• 0：producer不等待broker的ack，broker一接收到还没有写入磁盘就已经返回，可靠性最低；
• 1：producer等待broker的ack，partition的leader刷盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据，可靠性中；
• -1：producer等待broker的ack，partition的leader和follower全部落盘成功后才返回ack，数据一般不会丢失，延迟时间长但是可靠性高

消费者

设置enable.auto.commitrue，不管执行结果如何，消费者会自动提交offset。