消息中间件选型: kafka与rabbitmq的对比_消息中间件kafka,rabbitmq

作者：煮酒与君饮 | 2024-08-03 10:05:14

踩

消息中间件kafka,rabbitmq

RabbitMQ总结_陈海龙的格物之路-CSDN博客https://blog.csdn.net/chl87783255/article/details/122606212 kafka总结_陈海龙的格物之路-CSDN博客kafka，仅支持拉取的分布式流式平台。本文从简介、使用场景、设计、实现四个方面阐述kafka。https://blog.csdn.net/chl87783255/article/details/101360608通过阅读上述两篇文章，相信读者已经对kafka和rabbitmq有了全面的认识。接下来我会从多个维度，阐述kafka和rabbitmq的对比。

	kafka	rabbitmq
定位	事件流式平台	消息队列
数据交付方式	消费者从broker拉取消息	broker将消息推给消费者，不建议使用拉取方式
主要组件概念	主题分区	exchange binding queue
持久化	持久化到磁盘	持久化到磁盘，分为队列索引和消息存储。
生产者关注点	消息发布给哪个主题的哪个分区可理解为指定发给的队列	消息发布给哪个exchange(exchange的名称和类型) 消息对应的routingkey 无法指定发给哪个队列
消费者关注点	哪个主题的哪个分区，消息的offset	哪个exchange，哪个queue，bindingkey
消费者关注点	消费者收到消息后，自行过滤感兴趣的消息	bindingkey体现了过滤性，消费者可选择性添加过滤逻辑。
消费者压力	拉取方式，消费者可自行控制频率。	推送方式，但是消费者可以配置prefetch和人工确认，限制每个channel中未确认消息的条数。
消息交付给哪些消费者	只要消息没有被清理，则订阅了对应主题的所有消费者组都可以获取到消息。	消息到达broker时，与exchange连接且满足bindingkey条件的所有队列，每个队列仅将消息交付给某一个消费者。
队列长度、TTL	支持，主题的配置项，如清理方式，对log、segment的配置等	支持，创建队列时的配置项、发布消息时的配置项
消息路由	消费者组负责消息路由，消费者组的负载均衡策略	由broker负责路由
		通过bindingkey，将消息路由到队列
		队列中消息，通过round robin，每个消息路由给一个消费者
消息归属的队列	发布者发布的消息只属于指定主题的逻辑队列。	发布者发布的消息可以归属多个队列，与routingkey和bindingkey有关。
何时删除消息	与topic的清理规则有关	与队列TTL、长度由于；与消息TTL有关；
何时删除消息		每个队列中消息，一旦消费ack，则立即删除。
补偿消费	消息未被清理前，消费者可通过修改offset进行补偿消费	每个队列中消息一旦确认被消费，则直接从队列中删除，所以消费者无法补偿，只能要求发布者重发消息。
broker行为	接收消息，持久化到log；读取offset对应的消息	exchange到队列的路由；持久化；队列到消费者的路由
ack	生产消息ack	生产消息ack、消费消息ack

经过上述这些维度的对比，可以对消息中间件选型提供参考。

本文内容由网友自发贡献，转载请注明出处：【wpsshop博客】