RabbitMQ VS Kafka
PPTMQ.pptx比较内容KafkaRabbitMQ定位设计定位系统间的数据流管道，实时数据处理用于实时的，对可靠性要求较高的消息传递上 例如：常规的消息系统、网站活例如：订单，交易，充值，流计性跟踪，监控数据基础对比成熟度成熟:日志领域成熟成熟所属社区／公司ApacheMozilla Public License社区活跃度高...
·
PPTMQ.pptx
| 比较内容 | Kafka | RabbitMQ | |
|---|---|---|---|
| 定位 | 设计定位 | 系统间的数据流管道，实时数据处理 | 用于实时的，对可靠性要求较高的消息传递上 |
| 例如：常规的消息系统、网站活 | 例如：订单，交易，充值，流计 性跟踪，监控数据 | ||
| 基础对比 | 成熟度 | 成熟:日志领域成熟 | 成熟 |
| 所属社区／公司 | Apache | Mozilla Public License | |
| 社区活跃度 | 高 | 高 | |
| API完备性 | 高 | 高 | |
| 文档完备性 | 高 | 高 | |
| 开发语言 | Scala | Erlang | |
| 支持协议 | 仅支持自定义协议 | 支持AMQP、MQTT、STOMP协议 | |
| 客户端语言 | C/C++、Python、Go、 Java、 Erlang、NET、Ruby、Node.JS、PHP .. | Java、C、C++、Python、PHP、Perl | |
| 默认监控端口 | 无 | 15672 | |
| 默认数据端口 | 9092 | 5672 | |
| 持久化方式 | 磁盘文件(顺序追加磁盘,内存只是缓存思路,不是持久化思路,因为内存和磁盘会出现同一条数据, LSM的机制) | 内存+磁盘文件(数据分配比如50%内存,50%磁盘) | |
| 网络开销 | 相对较小(堆攒batch,相对小,不会频繁走network) 但是batch同时带来带宽大 | 相对较大 (就理解成一条条的刷,这里的优化只是channel级别的优化) | |
| 内存消耗 | 相对较小 (内存只是缓存) | 相对较大 (内存在放数据) | |
| cpu消耗 | CPU消耗大(压缩,分发,异步,同步复制,都需要消耗cpu) | 相对小 | |
| 部署方式 | 单机／集群(至少3台) | 单机／集群(至少3台) | |
| 是否支持事务性消息 | 支持 | 支持 | |
| 集群管理 | zookeeper | ||
| 选主方式 | 从ISR中自动选举一个leader | 最早加入集群的broker为主 | |
| 可用性 | 非常高:分布式、主从 | 高 :主从,数据量大的时候可能产生性能瓶颈 | |
| 是否支持topic优先级 | 不支持 | 支持 | |
| 是否支持消息全局有序 | 不支持 | 支持 | |
| 是否支持多个生产者 | 一个topic支持多个生产者 | 不支持 | |
| 元数据管理 | 通过zookeeper进行管理 | 支持消息数据持久 | |
| 元数据管理 | 通过zookeeper进行管理 | 支持消息数据持久 | |
可靠性比较 | 是否支持多个消费者 | 一个topic支持多个消费者(一个消费者可消费多个分区，一个分区可被多个消费组消费，但同一消费组内仅能有一个消费者同时消费1个分区) | 根据模式匹配 |
| 主从切换 | 自动切换: N个副本，允许N-1个失效： master失效以后自动从ISR中选一个为主. | 自动切换: 最早加入的slave会成为master. 新加入的slave回去同步之前master的数据, 但如果一直不能同步,可能会出现部分数据丢失. | |
| 数据可靠性 | |||
| 很好: 支持producer的单条发送、同步刷盘、异步复制 | 好: producer同步、异步ack，支持队列数据持久化，镜像模式中支持主从同步 | ||
| 消息写入性能/吞吐量 | 非常好 | 一般 | |
| 百万级/s 单机10w+/s 集群: 取决于规模 | 单机: 2w/s 集群: 4w/s | ||
| 性能的稳定性 | partition分区过多时性能不稳定，性能会明显下降 | 消息堆积时，性能不稳定、明显下降下降。 | |
| 消息堆积不影响性能的稳定性 | |||
| 单机支持的队列数 | 单机支持的队列数单机超过64个队列,Load会发生明显的飚高现象,队列越多,load越高,发送消息响应时长变长 | 依赖于可用内存有多大 | |
| 支持消息回溯，因为消息持久化，消息被消费后会记录offset和timstamp | 不支持，消息确认被消费后，会被删除 | ||
| 是否支持消息追踪 | 不支持消息追踪 | 支持消息追踪 | |
| broker 端的维护消息被消费的记录：一个消息被分发到 consumer 后 broker 就马上进行标记或者等待 customer 的通知后进行标记。这 样也可以在消息在消费后立马就删除以减少空间占用。 但是这样会不会有什么问题呢？如果一条消息发送出去之后就立即被标记为消费 过的，一旦 consumer 处理消息时失败了（比如程序崩溃）消息就丢失了 | 使用Trace实现，Trace是Rabbitmq用于记录每一次发送的消息，方便使用Rabbitmq的开发者调试、排错。可通过插件形式提供可视化界面。Trace启动后会自动创建系统Exchange：amq.rabbitmq.trace ,每个队列会自动绑定该Exchange，绑定后发送到队列的消息都会记录到Trace日志 | ||
| 堆积能力 | 非常好 | 一般 | |
消息存储在log中，每个分区由一个或多个segment log文件 | 生产者、消费者正常时，性能表现稳定； 消费者不消费时，消息堆积,可能会出现性能不稳定 | ||
| 复制备份 | 消息先写入leader的log， followers从leader中pull数据. pull到数据后先ack 到leader，然后写入log中。 | 普通模式下不复制； | |
| ISR中维护与leader同步的列表，落后太多的follwer会被删除掉. | 镜像模式下: 消息写先到master，然后写到slave上。 加入集群之前的已经到达的message不会被复制到新的slave上。 | ||
| 功能对比 | 消息投递的实时性 | 具体由consumer轮询间隔时间决定 | |
| 顺序消费 | 支持 | 支持 | |
| 但是一台Broker宕机后，可能会产生消息乱序 | |||
| 定时消息 | 不支持 | 可能支持(死信队列) | |
| 可以由其他计算框架配合支持 | RabbitMQ的死信队列详解 - 简书 | ||
| 消息查询 | 默认不支持,可以开发一些工具支持 | 默认不支持,可以开发一些工具支持 | |
| 消息失败重试 | 不支持 | 不支持 | |
| 消息重新消费 | 支持,修改offset 、timestamp、 | 不支持 | |
| 发送端的负载均衡 | 采用zookeeper对集群中的broker，consumer进行管理，可以注册topic到zookeeper上，通过zookeeper的协调机制，producer保存对应的topic的broker信息，可以随机或者轮询发送到broker上，producer可以基于语义指定分片，消息发送到broker的某个分片上。 | 需要单独的loadbalancer支持 | |
| 消息并行度 | 消费并行度和分区数一致. | 可以一次性抓取多条消息消费 | |
| 消费方式 | consumer pull | consumer pull /push | |
| 批量发送 | 支持;默认缓存、压缩、然后批量 | 不支持 | |
| 运维 | 消息清理策略 | 指定文件保存时间，过期删除 | consumer ack 以后， 消息将被标记 为删除(当内存少于40%，触发gc，将进行merge然后删除。) |
| 系统维护 | scala开发，维护成本高 | erlang开发，维护成本低 | |
| 部署依赖 | zookeeper | Erlang环境 | |
| 管理后台功能 | 官方不提供。 第三方开源工具可供使用。 | 官方提供 rabbitMQ- ui 界面 | |
| 权限管理 | 支持 (身份认证/权限控制) 1.身份认证:client 与服务器的连接进行身份认证，brokers和zookeeper之间的连接进行Authentication（producer 和 consumer）、其他 brokers、tools与 brokers 之间连接的认证。 2. 权限控制:(生产/消费/group)数据权限 | 支持 角色绑定自定义virtual hosts来控制数据的读写 Admin | Monitoring | Policymaker Management | Impersonator | |
| 管理后台功能/监控 | Kafak Web Console: producer Brokers leader/follower: ISR.HW Topic、Partition:logSize Consumer Groups/Consumer: Offset、Lag等信息 | Connections、 Channels、 Virtual Host Exchanges、 BindingKey Queues | |
| 生产和消费流里图、消息预览 | Binding: exchange和queue之间的虚拟连接，binding中可以包含routing key。Binding信息被保存到exchange中的查询表中，用于message的分发依据。 | ||
| broker 列表稳定 | Connection: publisher／consumer和broker之间的TCP连接。断开连接的操作只会在client端进行，Broker不会断开连接，除非出现网络故障或broker服务出现问题。 | ||
| Kafka Monitor: JMX/LOG/Consumer | Queue: 消息最终被送到这里等待consumer取走。一个message可以被同时拷贝到多个queue中。 | ||
| Kafka集群状态： 1.Topic、Consumer Group列表； 2.图形化展示topic和consumer之间 的关系： 3.图形化展示consumer的Offset、Lag等信息 | Exchange: message到达broker的第一站，根据分发规则，匹配查询表中的routing key，分发消息到queue中去。常用的类型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)。 | ||
| Kafka Manager Preferred leader: Brokers Spead:使用率 Brokers Skew: 是否倾斜 Brokers Leader Skew:partition是否倾斜 Lag:消息是否堆积产生延迟 | Channel: 如果每一次访问RabbitMQ都建立一个Connection，在消息量大的时候建立TCP Connection的开销将是巨大的，效率也较低。Channel作为轻量级的Connection极大减少了操作系统建立TCP connection的开销。 | ||
| 优点/缺点 | 1.监控集群的状态（topics，brokers，副本 分布，分区分布）； 2.产生分区分配（Generate partition assignments） 3.基于集群的当前 状态：重新分配分区 | Virtual host: 出于多租户和安全因素设计的，提供的服务时，可以划分出多个vhost，每个用户在自己的vhost创建exchange／queue等。 | |
| 扩容 | 数据迁移+扩容支持 ,脚本支持 | erlang 语言难度较大。集群不支持动态扩展 | |
| 时效性 | 延迟在 ms 级以内 | ms 级 | |
| 吞吐量 | 10w级 | 1w级 | |
| producer端提供缓存、压缩 | 支持多种客户端语言：支持amqp协议。 | ||
| 提供顺序消费能力 | 多种消费方式 | ||
| 提供多种客户端语言 | 使用RAM模式时，性能很好 | ||
| 生态完善，在大数据处理方面有很多配 套设施 | 管理界面较丰富，在互联网公司也有较大规模的应用； | ||
| 数据安全性 有保障,宣称0丢失. | |||
| 开启安全机制也会比较消耗性能 | |||
| 消费集群数目受到分区数目限制 | erlang 语言难度较大。集群不支持动态扩展 | ||
| 单机topic多时，性能会明显 | 消息堆积是，性能明显下降 | ||
| 支持支持事务会影响有延迟 | 支持支持事务会影响有延迟 |
Kafka开源项目指南提供详尽教程，助开发者掌握其架构、配置和使用，实现高效数据流管理和实时处理。它高性能、可扩展，适合日志收集和实时数据处理，通过持久化保障数据安全，是企业大数据生态系统的核心。
更多推荐
0
0- 0
已为社区贡献3条内容
所有评论(0)