RabbitMQ总结_陈海龙的格物之路-CSDN博客，仅支持拉取的分布式流式平台。本文从简介、使用场景、设计、实现四个方面阐述kafka。，相信读者已经对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 |
经过上述这些维度的对比，可以对消息中间件选型提供参考。
本文发布于:2024-01-29 03:12:11，感谢您对本站的认可！
本文链接：https://www.4u4v.net/it/170646915312282.html
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。
| 留言与评论（共有 0 条评论） |
