Kafka 和 RabbitMQ 都是流行的开源消息系统，它们可以在分布式系统中实现数据的可靠传输和处理。Kafka 和 RabbitMQ 有各自的优势和特点，它们适用于不同的场景和需求。本文将比较 Kafka 和 RabbitMQ 的主要区别，并分析何时使用 Kafka 而不是 RabbitMQ。

影响因素架构设计：RabbitMQ 的架构是专为复杂的消息路由而设计，RabbitMQ 使用推送模型。生产者可以使用不同的路由规则向使用者发送消息。Kafka 的架构是专为实时、高吞吐量的流处理场景设计，是一种基于分区的设计。Kafka 使用拉取模型，生产者向使用者订阅的主题和分区发布消息。性能：Kafka 的扩展方式是水平扩展（horizontal scaling），即通过增加集群中的节点数来提高性能和容量。因此在处理大容量、高吞吐量和实时数据流上性能优势很大，它每秒能够处理数百万个事件，并且可以处理大量数据。RabbitMQ 的扩展方式是垂直扩展（vertical scaling），即通过增加单个节点的硬件资源来提高性能和容量，因此它受到单个节点性能和容量的瓶颈，在性能方面是不如 Kafka 的。消息延迟：RabbitMQ 使用推送模型（push model），即交换机将消息推送到队列，然后队列将消息推送到消费者，这样可以减少消息在队列中的等待时间，降低延迟；Kafka 使用拉取模型（pull model），即生产者将消息发布到主题，然后消费者从主题拉取消息，这样可以增加消费者对消息的控制力，提高吞吐量，但也会增加延迟。因此在在延迟方面 Kafka 是不如 RabbitMQ 的。消息顺序：Kafka 保证了同一个分区（partition）内的消息是有序的，即按照生产者发送的顺序来存储和消费。但是不同分区之间的消息是无序的，即不能保证跨分区的消息按照全局顺序来处理。 RabbitMQ 保证了同一个队列内的消息是有序的，即按照先进先出（FIFO）的原则来存储和消费。但是不同队列之间的消息是无序的，即不能保证跨队列的消息按照全局顺序来处理。容灾机制：Kafka 通过副本（replica）机制来保证数据的可靠性，即每个主题可以有多个副本分布在不同的节点（broker）上，如果某个节点发生故障，可以自动切换到其他节点继续提供服务。 RabbitMQ 通过镜像（mirror）机制来保证数据的可靠性，即每个队列可以有多个镜像分布在不同的节点上，如果某个节点发生故障，可以自动切换到其他节点继续提供服务。消息持久化：Kafka 将数据持久化到磁盘中，并且支持数据压缩和批量传输，以提高性能和节省空间。Kafka 可以支持 TB 级别甚至 PB 级别的数据存储，并且可以快速地重放历史数据。RabbitMQ 将数据缓存在内存中，并且支持消息确认和事务机制，以提高可靠性和一致性。RabbitMQ 也可以将数据持久化到磁盘中，但是会降低性能和吞吐量。RabbitMQ 更适合处理小规模且实时性较高的数据。消息删除：RabbitMQ 支持消费者确认机制（consumer acknowledgement），即消费者在接收并处理完消息后向队列发送确认信号，队列才会删除该消息，这样可以保证消息的可靠传递；Kafka 不支持消费者确认机制，而是由消费者将消息附加到日志文件中，自己维护一个偏移量来记录已经消费过的消息，主题不会删除任何消息，该日志文件将一直留存到其保留期到期，除非达到预设的保留期限或大小限制。这样消费者可以在规定的时间内随时重新处理流式传输中的历史数据。消息路由：RabbitMQ 支持多种交换机类型，例如直接交换机（direct exchange）、主题交换机（topic exchange）、扇形交换机（fanout exchange）等，以实现不同的消息路由和分发策略；Kafka 不支持消息过滤，而是通过主题和分区来进行消息分类和分发。易用性：RabbitMQ 的安装和配置相对简单，只需要下载安装包并运行即可，也可以通过命令行或图形界面来管理和监控服务器状态；Kafka 的安装和配置相对复杂，需要依赖于 ZooKeeper 服务来协调集群状态，并且需要手动调整一些参数来优化性能和可靠性。因此在易用性上 RabbitMQ 是更简单的。应用场景

Kafka 适用场景和需求

跟踪高吞吐量的活动，如网站点击、应用日志、传感器数据等。事件溯源，Kafka 保存着所有历史消息，可以用于事件回溯和审计。流式处理，如实时分析、实时推荐、实时报警等。日志聚合，如收集不同来源的日志并统一存储和分析。

RabbitMQ 适用场景和需求

中小项目，项目消息量小、吞吐量不高、对延时敏感。遗留应用，如需要与旧系统或第三方系统进行集成或通信。复杂路由，如需要根据不同的规则或条件来分发或过滤消息。延迟敏感，对于消费者处理消息的及时性有非常高的要求。总结

在公司项目中，一般消息量都不大的情况下，博主推荐大家可以使用 RabbitMQ。消息量起来了可以考虑切换到 Kafka，但是也要根据公司内部对两种 MQ 的熟悉程度来进行选择，避免 MQ 出现问题时无法及时处理。

关注公众号【我不是架构师】每周分享技术干货、开源项目、实战经验、国外优质文章翻译等，您的关注将是我的更新动力！