🪴 Obsidian Publish

Kafka 的优缺点有哪些？选型问题？

6分钟阅读

Kafka 与周边生态系统的兼容性是最好的没有之一，设计上大量使用了批量和异步的思想，这种设计使得 Kafka 能做到超高的性能（大约每秒钟可以处理几十万条消息）

Kafka 这种异步批量的设计带来的问题是，它的同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka 并不会立即发送出去，而是要等一会儿攒一批再发送。
业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反而会比较高。所以，Kafka 不太适合在线业务场景。

优点

  • 高性能、高吞吐量、低延迟：Kafka 生产和消费消息的速度都达到每秒 10 万级
  • 高可用：所有消息持久化存储到磁盘，并支持数据备份防止数据丢失
  • 高并发：支持数千个客户端同时读写
  • 容错性：允许集群中节点失败（若副本数量为 n，则允许 n-1 个节点失败）
  • 高扩展性：Kafka 集群支持热伸缩，无须停机

缺点

  • 仅支持统一分区内消息有序，无法实现全局消息有序；
  • 没有完整的监控工具集
  • 不支持通配符主题选择
  • 由于是批量发送，数据并非真正的实时；
  • 对于 mqtt 协议不支持；
  • 不支持物联网传感数据直接接入；
  • 依赖 zookeeper 进行元数据管理；
  • 异步处理带来了延迟的问题

其他 MQ

RabbitMQ VS Kafka

  1. 性能方面：Kafka 自身支持水平扩展，且批处理+异步机制，使得性能更好。
  2. 消息延迟：Kafka 批处理+异步机制，消息延迟会较高
  3. 消息持久化：Kafka 将数据持久化到磁盘中，并且支持数据压缩和批量传输，以提高性能和节省空间。Kafka 可以支持 TB 级别甚至 PB 级别的数据存储，并且可以快速地重放历史数据。RabbitMQ 将数据缓存在内存中，并且支持消息确认和事务机制，以提高可靠性和一致性。RabbitMQ 也可以将数据持久化到磁盘中，但是会降低性能和吞吐量。RabbitMQ 更适合处理小规模且实时性较高的数据。
  4. 消息删除：RabbitMQ 支持消费者确认机制（consumer acknowledgement），即消费者在接收并处理完消息后向队列发送确认信号，队列才会删除该消息，这样可以保证消息的可靠传递；Kafka 不支持消费者确认机制，而是由消费者将消息附加到日志文件中，自己维护一个偏移量来记录已经消费过的消息，主题不会删除任何消息，该日志文件将一直留存到其保留期到期，除非达到预设的保留期限或大小限制。这样消费者可以在规定的时间内随时重新处理流式传输中的历史数据。

Kafka 适用场景和需求

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

RabbitMQ 适用场景和需求

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

Kafka、RabbitMQ、RocketMQ 的区别-CSDN 博客
何时使用 Kafka 而不是 RabbitMQKafka 和 RabbitMQ 都是流行的开源消息系统，它们可以在分布式系统中 - 掘金

传统队列系统 VS Kafka

  • 消息保留
    • 传统的队列系统 - 它通常从队列末尾处理完成后删除消息。
    • Apache Kafka 中，消息即使在处理后仍然存在。这意味着 Kafka 中的消息不会因消费者收到消息而被删除。
  • 基于逻辑的处理
    • 传统队列系统不允许基于类似消息或事件处理逻辑。
    • Apache Kafka 允许基于类似消息或事件处理逻辑。
  • Sub/Pub 机制的消息队列，不一定支持多个消费者组消费一个 topic

反向链接