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
影响因素
- 可扩展性：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 更容易设置和使用。
应用场景
Kafka 适用场景和需求
- 跟踪高吞吐量的活动，如网站点击、应用日志、传感器数据等。
- 事件溯源，Kafka 保存着所有历史消息，可以用于事件回溯和审计。
- 流式处理，如实时分析、实时推荐、实时报警等。
- 日志聚合，如收集不同来源的日志并统一存储和分析。
RabbitMQ 适用场景和需求
- 中小项目，项目消息量小、吞吐量不高、对延时敏感。
- 遗留应用，如需要与旧系统或第三方系统进行集成或通信。
- 复杂路由，如需要根据不同的规则或条件来分发或过滤消息。
- 任务分发，如需要将任务均匀地分配给多个工作进程或消费者。
总结
在公司项目中，一般消息量都不大的情况下，博主推荐大家可以使用 RabbitMQ。消息量起来了可以考虑切换到 Kafka，但是也要根据公司内部对两种 MQ 的熟悉程度来进行选择，避免 MQ 出现问题时无法及时处理。
