1. 何时使用 Kafka 而不是 RabbitMQ
Kafka 和 RabbitMQ 都是流行的开源消息系统, 它们可以在分布式系统中实现数据的可靠传输和处理。Kafka 和 RabbitMQ 有各自的优势和特点, 它们适用于不同的场景和需求。本文将比较 Kafka 和 RabbitMQ 的主要区别, 并分析何时使用 Kafka 而不是 RabbitMQ。
推荐博主开源的 H5 商城项目 waynboot-mall, 这是一套全部开源的微商城项目, 包含一个运营后台、h5 商城和后台接口。 实现了一个商城所需的首页展示、商品分类、商品详情、sku 详情、商品搜索、加入购物车、结算下单、订单状态流转、商品评论等一系列功能。 技术上基于最新得 Springboot3.0、jdk17, 整合了 Redis、RabbitMQ、ElasticSearch 等常用中间件, 贴近生产环境实际经验开发而来不断完善、优化、改进中。
github 地址: https://github.com/wayn111/waynboot-mall
1.1. 影响因素
- 可扩展性: Kafka 旨在处理大容量、高吞吐量和实时数据流。它每秒能够处理数百万个事件, 并且可以处理大量数据。另一方面, RabbitMQ 的设计更加灵活, 可以处理广泛的用例, 但可能不太适合大容量、实时数据流。
- 耐用性: Kafka 通过将所有数据写入磁盘来提供高度的耐用性, 这对于任务关键型应用程序非常重要。 RabbitMQ 还提供基于磁盘的持久性, 但这可能不如 Kafka 提供的那么强大。
- 延迟: RabbitMQ 设计为低延迟, 这对于实时数据处理和分析非常重要。由于其更灵活的架构, Kafka 可以具有更高的延迟。
- 数据流: Kafka 使用无界的数据流, 即数据持续地流入到指定的主题(topic)中, 不会被删除或过期, 除非达到了预设的保留期限或容量限制。RabbitMQ 使用有界的数据流, 即数据被生产者(producer)创建并发送到消费者(consumer), 一旦被消费或者达到了过期时间, 就会从队列(queue)中删除。
- 数据使用: Kafka 支持多个消费者同时订阅同一个主题, 并且可以根据自己的进度来消费数据, 不会影响其他消费者。这意味着 Kafka 可以支持多种用途和场景, 比如实时分析、日志聚合、事件驱动等。RabbitMQ 的消费者从一个队列中消费数据, 一旦被消费, 就不会再被该队列其他消费者看到。这意味着 RabbitMQ 更适合一对一的通信或任务分发。
- 数据顺序: Kafka 保证了同一个分区(partition)内的数据是有序的, 即按照生产者发送的顺序来存储和消费。但是不同分区之间的数据是无序的, 即不能保证跨分区的数据按照全局顺序来处理。 RabbitMQ 保证了同一个队列内的数据是有序的, 即按照先进先出(FIFO)的原则来存储和消费。但是不同队列之间的数据是无序的, 即不能保证跨队列的数据按照全局顺序来处理。
- 数据可靠性: Kafka 通过副本(replica)机制来保证数据的可靠性, 即每个主题可以有多个副本分布在不同的节点(broker)上, 如果某个节点发生故障, 可以自动切换到其他节点继续提供服务。 RabbitMQ 通过镜像(mirror)机制来保证数据的可靠性, 即每个队列可以有多个镜像分布在不同的节点上, 如果某个节点发生故障, 可以自动切换到其他节点继续提供服务。
- 数据持久性: Kafka 将数据持久化到磁盘中, 并且支持数据压缩和批量传输, 以提高性能和节省空间。Kafka 可以支持 TB 级别甚至 PB 级别的数据存储, 并且可以快速地重放历史数据。RabbitMQ 将数据缓存在内存中, 并且支持消息确认和事务机制, 以提高可靠性和一致性。RabbitMQ 也可以将数据持久化到磁盘中, 但是会降低性能和吞吐量。RabbitMQ 更适合处理小规模且实时性较高的数据。
- 数据扩展性: Kafka 通过分区机制来实现水平扩展, 即每个主题可以划分为多个分区, 并且可以动态地增加或减少分区数量
- 复杂性: 与 RabbitMQ 相比, Apache Kafka 具有更复杂的架构, 并且可能需要更多的设置和配置。然而, 它的复杂性也允许更高级的功能和定制。另一方面, RabbitMQ 更容易设置和使用。
1.2. 应用场景
Kafka 适用场景和需求
- 跟踪高吞吐量的活动, 如网站点击、应用日志、传感器数据等。
- 事件溯源, Kafka 保存着所有历史消息, 可以用于事件回溯和审计。
- 流式处理, 如实时分析、实时推荐、实时报警等。
- 日志聚合, 如收集不同来源的日志并统一存储和分析。
RabbitMQ 适用场景和需求
- 中小项目, 项目消息量小、吞吐量不高、对延时敏感。
- 遗留应用, 如需要与旧系统或第三方系统进行集成或通信。
- 复杂路由, 如需要根据不同的规则或条件来分发或过滤消息。
- 任务分发, 如需要将任务均匀地分配给多个工作进程或消费者。
1.3. 总结
在公司项目中, 一般消息量都不大的情况下, 博主推荐大家可以使用 RabbitMQ。消息量起来了可以考虑切换到 Kafka, 但是也要根据公司内部对两种 MQ 的熟悉程度来进行选择, 避免 MQ 出现问题时无法及时处理。