Kinesis根據文檔至少有一次語義學。我試圖找出一種方法來確保檢測到重複項。如果有重複的記錄，是否有保證它會來自原始記錄的相同碎片？我問的原因是這將決定我的重複檢測是否需要「全局」，因爲如果我有多個實例正在處理一個流，我是否需要檢測這些實例中的重複項？如果重複來自同一個分片，那麼這意味着最有可能同一個記錄處理器將看到重複（並且肯定是相同的實例），然後我的重複檢測對於該實例可以是「本地」的。Kinesis至少有一次語義學
決定性的答案是檢查後備存儲或索引以查看記錄是否已被插入（DynamoDB，Redshift，RDS等）。將數據存儲與Kinesis處理器實例分開是最佳實踐，因此您只需檢查一個位置即可。有幾種方法可以做到這一點，這可能是另一個問題的主題。
如果您使用的是KCL，那麼它會自行處理碎片，並且您需要處理它們而被抽象化。使用KCL，您的實例消耗的碎片可能隨時間而改變因此，我不建議創建一個依賴於始終從同一分片接收數據的實例的系統。
要回答這個問題，如果一個碎片消耗了一次獨立記錄並且（無論出於何種原因）再次出現，它將是第二次來自同一碎片，因爲它的分區密鑰不會改變。
注意：記錄通常只會在該記錄批次第一次發送失敗時再次收到。
謝謝克里斯。是的，我正在使用KCL。所以我猜這個實例可能會改變，儘管碎片保持不變。我絕對需要一些能夠將處理記錄中由此檢查引入的延遲降到最低的東西。目前，DynamoDB和Redis/Memcached似乎是最有吸引力的選擇。如果你對此有任何想法，這將有所幫助。 –
是的，這些都是不錯的選擇。取決於你的數據大小和結構，這些都是很好的選擇，因爲它們的速度和規模。如果你的對象存儲不能快速查詢（例如S3），你可以考慮在（比方說）發電機中託管插入的記錄ID（和位置）的索引。如果你爲此使用發電機，請確保使用一致的讀數。 –
在我使用過Kinesis的情況下，由於數據規模較大（至於Kinesis最適合），所以至少一次的語義並不成問題。也就是說，如果我們有1M個日誌記錄，則少數是否重複也無關緊要。此外，當您處於查詢時時，您可以使用對不同記錄ID的查詢來消除結果中的重複項（這是我通常使用的方法，而不是嘗試在途中清理數據）。當然，也有一些使用情況，一次或原子處理是至關重要的。 –