SQS和Kafka一样吗?

use*_*277 43 amazon-sqs apache-kafka

Kafka 和 SQS 一样吗?我发现两者都是消息队列系统并且是基于事件的。它们的目的相同吗?如果不是,它们有何不同?

Md.*_*man 47

Apache Kafka 和 Amazon SQS 都用于消息流,但并不相同。

Apache Kafka 遵循发布订阅者模型,其中生产者将事件/消息发送到某个主题,一个或多个消费者订阅该主题以获取事件/消息。在本主题中,您将找到并行流的分区。曾经有一个消费群体的概念。当从主题分区读取消息时,将致力于标识该消息已被该消费者组读取,以避免并发编程中读取的不一致。但是,其他消费者组仍然可以从该分区读取该消息。

其中,Amazon SQS 遵循队列,并且可以在 Amazon SQS 的任何区域中创建队列。您可以将消息推送到队列,并且只有一个消费者可以订阅每个队列并从队列中提取消息。这就是 SQS 是基于拉取的流式传输的原因。SQS 队列有两种类型:FIFO 和标准。

AWS中还有一个概念是Amazon SNS,它像Kafka一样基于订阅者发布,但SNS中没有任何消息保留策略。它用于即时消息传递,如电子邮件、短信等。它只能在订阅者空闲时向订阅者推送消息。否则,消息将会丢失。然而,SQS 与 SNS 可以克服这个缺点。带有 SQS 的 Amazon SNS 称为扇出模式。在此模式中,发布到 SNS 主题的消息将并行分发到多个 SQS 队列,并且 SQS 队列确保持久性,因为 SQS 具有保留策略。它可以将消息保留长达 14 天(默认 4 天)。Amazon SQS with SNS 可以实现高吞吐量并行流,并且可以取代 Apache Kafka。


小智 14

是的,它们是两个消息系统,但有区别:

卡夫卡

Kafka 是一个非常可扩展的系统,当您想要批量发送消息(以获得良好的消息吞吐量)时,适合高工作负载。

Kafka 主题由一定数量的分区组成,一个消费者组中的不同消费者可以完全并行地读取这些分区,这给我们带来了非常好的性能。
例如,如果你需要构建一个高负载的流系统,Kafka就非常适合它。

质量安全体系

SQS 是一项 Amazon 托管服务(因此您不必自己支持基础设施)。

当您需要捕获某个客户端的某些消息(事件)时,SQS 更适合事件处理,然后该消息将自动从队列中弹出。

就我的经验而言,SQS 不如 Kafka 快,也不适合高工作负载,它更适合每秒事件数不太多的事件。

例如,如果您想对某些 S3 文件上传做出反应(开始对该文件进行某些处理),SQS 就非常好。

  • 我很欣赏这段文字,但是“巨大的区别”是什么?... (23认同)

Nil*_*ndu 13

SQS和Kafka都是消息系统。主要区别是:

  • 大规模订购。Kafka - 生成的消息始终按顺序消费,无论队列中的项目数量如何。SQS - “FIFO 队列会查看前 20k 消息以确定可用的消息组。这意味着,如果单个消息组中有积压的消息,则无法使用发送到队列的其他消息组中的消息稍后直到您成功使用积压中的消息”
  • Kafka组/主题/分区数量的限制 - 尽管限制相当高,但主题/分区的数量通常为数千(可能会根据集群大小而增加)。SQS - “FIFO 队列中的消息组数量没有配额。”
  • 重复数据删除- Kafka 不支持重复数据删除,以免多次生成相同的数据。SQS 尝试根据 dedup-id 和 dedup-interval 对消息进行去重。“假设生产者在重复数据删除间隔到期之前至少收到一个确认,则多次重试既不会影响消息的排序,也不会引入重复项。”
  • 分区管理。Kafka - 分区的创建或添加由用户创建和管理。SQS 控制分区数量,并且可以根据负载和使用模式增加或减少分区数量。
  • 死信队列——Kafka没有DL队列的概念(它可以由用户思想显式地创建和维护)。SQS 本身就支持 DL 队列。

总的来说,如果我们想总结以上几点,我们可以说 SQS 旨在将后台任务卸载到异步管道。Kafka 更具可扩展性,应该用作流处理管道。