除了上面提到的几点之外，上面提到的几点真的很有帮助
多租户sqs/sns非常困难，现在可能有办法为每个租户创建单独的队列（很难维护）
kafka是可群集的，群集实时连接到应用程序和数据库，并提供数据的键/值访问。对于每条消息的保留期，分发和复制都有较大的优势——其中sqs更像是一个黑匣子，发送消息并接收，接收标记它已处理和删除。

kafka和amazonsqs/amazonsns的用例完全不同。
正如您所写的，kafka是一个分布式发布-订阅系统。它是为非常高的吞吐量而设计的，每秒处理数千条消息。当然，您需要自己设置和集群它。它支持多个读卡器，这些读卡器可以随时“赶上”消息流（只要消息仍在磁盘上）。您可以将其用作队列（使用使用者组）和主题。
一个重要的特性是，您不能有选择地将消息确认为“已处理”；唯一的选择是在一定的偏移量内确认所有消息。
另一方面，sqs/sns：
无设置/无维护
队列（sqs）或主题（sns）
各种限制（大小、消息寿命等）
吞吐量有限：您可以执行批处理和并发请求，但仍然要实现高吞吐量将是非常昂贵的
我不确定消息是否被复制；但是，至少有一次在sqs中保证交货会建议这样做
sns内置了电子邮件、短信、sqs和http通知。有了Kafka，你可能需要自己编写代码
没有“消息流”概念
所以总的来说，我想说sqs/sns非常适合于更简单的任务和工作负载，并且消息量更低。

这是一个典型的权衡：

aws工具（sqs、sns）

这些将更易于设置，并与体系结构的其余部分集成，特别是如果大部分体系结构已经在aws上运行的话。一开始可能会更便宜，因为他们有一个很好的现收现付模式，但成本不会扩大，所以你必须考虑这一点。

Apache·Kafka

在这里，您使用的是一个非常流行（而不是流行）的分布式（如果您认为您将扩展很多，这一点很重要）pub/sub模型。现在，这种模型似乎更受欢迎，因为对通过管道的数据运行分析是非常常见的，而且通常在soa架构中，您可以有许多小型服务使用消息并执行它们的任务，而不必将数据从队列中移除。您还可以获得许多配置选项，因此根据您的用例，您可以根据需要对其进行微调。这意味着更多的工作，但更优化的服务的道路。

摘要

这是在开发速度和开发易用性与最佳、非常模块化和个性化的解决方案之间的一个经典折衷，该解决方案在第一次实现时有更多的开销，但可扩展性更好。

个人建议

如果你是原型化的东西，赞成开发速度，所以aws工具。如果你的需求被冻结并且需要很大的规模，那么一定要花时间使用Kafka。我也非常相信使用开源可以让世界变得更好，但这并不是使用开源的最大理由。