Kinesis支持多消费者功能，这意味着相同的数据记录可以在同一时间或24小时内不同的时间在不同的消费者处处理，SQS中的类似行为可以通过写入多个队列实现，消费者可以从多个队列中读取。然而，再次写入多个队列将在系统中增加几秒(几毫秒)的延迟。

其次，Kinesis提供了路由功能，可以使用分区键将数据记录选择性地路由到不同的分片，这些分区键可以由特定的EC2实例处理，并可以启用微批处理计算{计数和聚合}。

使用任何AWS软件都很容易，但使用SQS是最简单的。使用Kinesis，需要提前提供足够的碎片，动态增加碎片数量以管理尖峰负载，并减少以节省管理所需的成本。这是运动的疼痛，SQS不需要这样的事情。SQS是无限可伸缩的。

从表面上看，它们有点相似，但是用例将决定哪种工具是合适的。在我看来，如果你可以使用SQS，那么你应该——如果它能做你想做的事情，它会更简单、更便宜，但这里有一个来自AWS FAQ的更好解释，它给出了两个工具的适当用例示例，以帮助你决定:

常见问题的

请记住，这个答案在2015年6月是正确的

在研究了这个问题一段时间后，我心里有同样的问题，我发现SQS(带SNS)是大多数用例的首选，除非消息的顺序对您很重要(SQS不保证消息的FIFO)。

Kinesis有2个主要优势:

您可以从多个应用程序读取相同的消息 如果需要的话，您可以重新阅读邮件。

这两个优点都可以通过使用SNS作为SQS的扇出来实现。这意味着消息的生产者只向SNS发送一条消息，然后SNS将消息分散到多个SQSs，每个使用者应用程序一个SQSs。通过这种方式，您可以拥有尽可能多的消费者，而无需考虑分片容量。

此外，我们还增加了一个订阅SNS的SQS，可以保存14天的消息。在正常情况下，没有人从这个SQS中读取数据，但如果出现让我们想要倒带数据的错误，我们可以轻松地从这个SQS中读取所有消息，并将它们重新发送到SNS。而Kinesis仅提供7天的留存。

总之，SNS+SQSs更简单，提供了大部分功能。在我看来，你需要一个非常有力的案例来选择Kinesis。

我还要补充一件没人提到过的事情——SQS要贵几个数量级。

这些技术的语义不同，因为它们是为支持不同的场景而设计的:

SNS/SQS:流中的项之间没有关联 运动:流中的项目相互关联

让我们通过例子来理解其中的区别。

Suppose we have a stream of orders, for each order we need to reserve some stock and schedule a delivery. Once this is complete, we can safely remove the item from the stream and start processing the next order. We are fully done with the previous order before we start the next one. Again, we have the same stream of orders, but now our goal is to group orders by destinations. Once we have, say, 10 orders to the same place, we want to deliver them together (delivery optimization). Now the story is different: when we get a new item from the stream, we cannot finish processing it; rather we "wait" for more items to come in order to meet our goal. Moreover, if the processor process crashes, we must "restore" the state (so no order will be lost).

一旦一个项目的处理不能与另一个项目的处理分离，我们就必须有运动语义，以便安全地处理所有的情况。

对我来说，最大的优势是Kinesis是一个可重玩的队列，而SQS不是。因此，您可以有多个Kinesis的相同消息的消费者(或在不同时间的相同消费者)，而在SQS中，一旦消息被ack，它就从队列中消失了。 因此，SQS更适合工作者队列。