Kinesis根据文档至少有一次语义学。我试图找出一种方法来确保检测到重复项。如果有重复的记录，是否有保证它会来自原始记录的相同碎片？我问的原因是这将决定我的重复检测是否需要“全局”，因为如果我有多个实例正在处理一个流，我是否需要检测这些实例中的重复项？如果重复来自同一个分片，那么这意味着最有可能同一个记录处理器将看到重复（并且肯定是相同的实例），然后我的重复检测对于该实例可以是“本地”的。Kinesis至少有一次语义学
决定性的答案是检查后备存储或索引以查看记录是否已被插入（DynamoDB，Redshift，RDS等）。将数据存储与Kinesis处理器实例分开是最佳实践，因此您只需检查一个位置即可。有几种方法可以做到这一点，这可能是另一个问题的主题。
如果您使用的是KCL，那么它会自行处理碎片，并且您需要处理它们而被抽象化。使用KCL，您的实例消耗的碎片可能随时间而改变因此，我不建议创建一个依赖于始终从同一分片接收数据的实例的系统。
要回答这个问题，如果一个碎片消耗了一次独立记录并且（无论出于何种原因）再次出现，它将是第二次来自同一碎片，因为它的分区密钥不会改变。
注意：记录通常只会在该记录批次第一次发送失败时再次收到。
谢谢克里斯。是的，我正在使用KCL。所以我猜这个实例可能会改变，尽管碎片保持不变。我绝对需要一些能够将处理记录中由此检查引入的延迟降到最低的东西。目前，DynamoDB和Redis/Memcached似乎是最有吸引力的选择。如果你对此有任何想法，这将有所帮助。 –
是的，这些都是不错的选择。取决于你的数据大小和结构，这些都是很好的选择，因为它们的速度和规模。如果你的对象存储不能快速查询（例如S3），你可以考虑在（比方说）发电机中托管插入的记录ID（和位置）的索引。如果你为此使用发电机，请确保使用一致的读数。 –
在我使用过Kinesis的情况下，由于数据规模较大（至于Kinesis最适合），所以至少一次的语义并不成问题。也就是说，如果我们有1M个日志记录，则少数是否重复也无关紧要。此外，当您处于查询时时，您可以使用对不同记录ID的查询来消除结果中的重复项（这是我通常使用的方法，而不是尝试在途中清理数据）。当然，也有一些使用情况，一次或原子处理是至关重要的。 –