Apache Kafka 和 Amazon SQS 都 用于 消息 流 ， 但 并 不 相同 。
ApacheKafka 遵循 发布 订阅 者 模型 ，其中 生产 者 向 主题 发送 事件/消息 ， 一 个 或 多 个 消费 者 订阅 该 主题 以 获取 事件/消息 。 在 主题 中 ， 您 可以 找到 用于 并行 流 的 分区 。 曾经 有 一 个 消费 者 组 概念 。 当 从 主题 的 分区 读取 消息 时 ， 它 将 被 提交 以 标识 其 已 被 该 消费 者 组 读取 ， 以 避免 并发 编程 中 读取 的 不 一致 。但是 ， 其他 使用 者 组 仍然 可以 从 该 分区 读取 该 消息 。
其中 ， Amazon SQS 跟随 Queue ， 并且 可以 在 Amazon SQS 的 任何 区域 创建 队列 。 您 可以 将 消息 推送 到 Queue ， 并且 只有 一 个 使用 者 可以 订阅 每个 Queue ， 并且 可以 从 Queue 中 拉 取 消息 。 这 就是 SQS 基于 流 的 原因 。 SQS 队列 有 两 种 类型 ：FIFO 和 标准 。
AWS 中 还有 一 个 概念 是 Amazon SNS ， 它 像 Kafka 一样 基于 发布 订阅 者 ， 但 SNS 中 没有 任何 消息 保留 策略 。 它 用于 即时 消息 ， 如 电子 邮件 、 短信 等 。 只有 当 订阅 者 有空 时 ， 它 才 能 将 消息 推 送给 订阅 者 。 否则 消息 会 丢失 。 然而 ， 带有 SNS 的 SQS 可以 克服 这个 缺点 。 带有 SQS 的 Amazon SNS 被 称为 扇出 模式 。 在 这种 模式 中 ，发布 到 SNS 主题 的 消息 被 并行 地 分发 到 多 个 SQS 队列 中 ， SQS 队列 保证 了 持久 性 ， 因为 SQS 具有 保留 策略 ， 它 可以 将 消息 持久 化 长达 14 天 （ 默认 为 4 天 ） 。 2 带有 SNS 的 Amazon SQS 可以 实现 高 吞吐 量 的 并行 流 ， 可以 替代 Apache Kafka 。

是 的 ， 它们 是 两 种 消息 传递 系统 ， 但 有 一 个 很 大 的 区别 ：

• Kafka

Kafka 是 一 个 可 伸缩 性 很 好 的 系统 ， 当 您 希望 批量 发送 消息 （ 以 获得 良好 的 消息 吞吐 量 ） 时 ， 它 适合 高 工作 负载 。
Kafka 主题 由 一定 数量 的 分区 组成 ， 这些 分区 可以 被 一 个 消费 者 组 中 的 不同 消费 者 完全 并行 地 读取 ， 这 给 了 我们 非常 好 的 性能 。
比如 ， 如果 你 需要 构建 一 个 高 负载 的 流 媒体 系统 ， Kafka 确实 很 适合 。

• 质量 标准

SQS 是 Amazon 托管 服务 （ 因此 您 不必 自己 支持 基础 架构 ） 。
当 您 需要 捕获 某 个 客户 端 的 某 个 消息 （ 事件 ） ， 然后 该 消息 将 自动 从 队列 中 弹出 时 ， SQS 更 适合 于 事件 处理 。
就 我 的 经验 而言 ， SQS 没有 Kafka 那么 快 ， 也 不 适合 高 工作 负载 ， 它 更 适合 每秒 事件 计数 不是 那么 多 的 事件 。
例如 ， 如果 你 想 对 一些 S3 文件 上传 做出 React （ 开始 对 这个 文件 进行 一些 处理 ） ， SQS 是 非常 好 的 。

SQS和Kafka都是消息传递系统，主要区别在于：

*按规模排序. Kafka -生成的消息总是按顺序使用，而与队列中的项数无关。SQS -“FIFO队列查看前20 k条消息，以确定可用的消息组。这意味着，如果单个消息组中有消息积压，在成功使用积压中的消息之前，无法使用稍后发送到队列的其他消息组中的消息”
*对组/主题/分区数量的限制Kafka -虽然限制很高，但主题/分区的数量通常为数千个（可以根据集群大小增加）。SQS -“FIFO队列中的消息组数量没有配额。”
*重复数据删除- Kafka不支持重复数据删除，以防多次生成相同的数据。SQS尝试根据dedup-id和dedup-interval对消息进行重复数据删除。“假设生成器在重复数据删除间隔到期之前至少收到一个确认，则多次重试既不会影响消息的排序，也不会引入重复。”
*分区管理. Kafka -分区的创建或添加由用户创建和管理。SQS控制分区的数量，它可以根据负载和使用模式增加或减少分区的数量。
*死信队列- Kafka没有DL队列的概念（它可以通过用户的想法显式地创建和维护）。SQS本身固有地支持DL队列。

总的来说，如果我们想总结以上几点，我们可以说SQS是为了将后台任务卸载到异步管道。Kafka更具可伸缩性，应该用作流处理管道。

SQS是一个队列。您有一个需要由应用程序的其他部分处理的消息列表。理想情况下，一个消息只由一个处理器处理一次，然后标记为已处理并从队列中删除。队列的用途是在不同的处理器之间协调和分配消息处理。
Kafka更类似于Kinesis，主要用于数据流。消息被存储在主题中，供其他组件读取。任何组件都可以在任何时候监听主题和/或读取所有消息。主要目的是允许将消息高效地传递给任意数量的接收者，并允许以动态和弹性的方式在组件之间连续地传输数据。

从鸟类的Angular 来看，有一个主要的区别

1. Kafka用于pub sub模型。如果一个生产者发送单个消息。如果一个Kafka主题有两个消费者，则两个消费者都将收到消息
2. SQS更像是竞争使用者模式。如果一个生成器发送一条消息，而SQS有两个使用者。则只有一个使用者会收到该消息。如果第一个使用者成功处理了该消息，则另一个使用者不会收到该消息。只有在消息可见性超时时，第二个使用者才有机会收到该消息。即，第一个使用者无法在给定时间内处理消息，也无法在可见性超时内删除消息。