为什么在这种情况下使用带有 groupID 的 SQS FIFO 而不是使用带有分区键的 Kinesis Streams？

Question

我正准备参加 AWS Solutions architecture Associate level certificate 的考试，我遇到了一个非常棘手的问题：

我认为 Kinesis Streams 是一个很好的解决方案，我们从多个来源接收数据，消费者的数量现在如问题所述。因此，在这种情况下，分片数量与桌面数量相同的流数据非常适合。 我原则上没有看到带有 groupe ID 的 SQS FIFO 是一种可能的解决方案，它可以从多个来源接收数据，并可以使用 group id 以间歇的方式传递给多个消费者，但不能保证消息会被传递到带有 SQS FIFO 和 GROUPID 的右侧桌面。这将取决于消费者如何从 SQS 请求消息：

SQS FIFO 文档

使用 kinesis 不会有问题，因为您为每个消费者创建了一个分片，并且由于分区键和分片的性质（记录按顺序交付给消费者），它保证消息将按正确的顺序传递consumer.SO，在这种情况下，我不明白为什么带有组 ID 的 SQS FIFO 是比 Kinesis Streams 更好的解决方案。

在这种情况下，有人可以解释为什么带有 groupID 的 SQS FIFO 是比 Kinesis Streams 更好的解决方案吗？

Answer 1

Kinesis 解决方案的问题在于它在分区键的 MD5 散列上进行分片。这意味着潜在的冲突，因此多个桌面系统遥测将在同一个分片中。

SQS FIFO 方法使用消息组 ID。如果每个桌面都分配了一个唯一的消息组 ID，那么来自给定桌面的所有消息都将在其自己的唯一消息组中，因此可以独立于任何其他桌面进行处理。