我有一個消費者，我懷疑是比默認消息可見性更長的時間來處理給定的消息，但最終成功。如果我刪除另一個消費者收到的SQS消息，會發生什麼情況？
Consumer A得到收據R1M1的消息M1Consumer B得到收據R2M1的消息M1Consumer A電話deleteMessage(R1M1)的消息中刪除，還是留在隊列中，罪惡另一個消費者是否擁有更有效的消息收據？
我在觀察我的隊列中的許多更復雜的消息有很多（50-1000）收據，但我沒有記錄任何失敗來處理消息。我懷疑我多次成功處理每條消息，然後刪除操作默默地失敗。
API參考文獻實際上與此相矛盾on the same page。
DeleteMessage可以
刪除從指定的隊列中的指定的消息。您通過使用消息的收據處理來指定消息，而不是您在發送消息時收到的
MessageId。即使郵件由於可見性超時設置而被另一個閱讀器鎖定，它仍然會從隊列中刪除。
這似乎很直截了當，直到你繼續閱讀。
注
收據手柄與接收消息的特定實例相關聯。如果您多次收到一條消息，每次收到消息時收到的收據句柄都會有所不同。如果您在使用
DeleteMessage操作時未提供最近收到的郵件的收據處理，則該請求會成功，但該郵件可能不會被刪除。
所以，你的問題的答案是「是的，絕對的，除了沒有，不一定。」
但它解釋了爲什麼你會有沉默失敗 - 如果請求有效，刪除顯然不會失敗。
這可能是SQS分佈式特性的基本工件 - 如果SQS中傳遞該消息的特定節點發生故障，則可能是舊的消息收據可能丟失。當然，我在猜測。
從根本上講，如果遇到這種情況，您似乎確實有設計缺陷。您要麼發送後續請求來增加可見性超時，要麼將默認可見性超時設置得足夠高以至於在正常情況下永遠不會發生。最大值爲12小時，對於大多數使用情況來說這個時間要長得多。
此外，您的消費者需要一種方法來驗證消息是否已被執行。
將可見性超時視爲重試計時器。
我的基礎架構中的一個示例是一個系統，它對在S3中放入臨時分段存儲桶的文件作出反應。隊列使用者查找文件，並執行一些數據庫查詢以確定哪個或哪些系統可能需要該文件。然後它將文件複製到目標系統桶中，並且根據規則，它可以創建數據庫條目和/或將消息發送到不同的隊列以處理該文件。通常會在短時間內發生這種情況，如果一切順利，消息將從隊列中刪除。如果出現問題，它只會忘記消息並返回輪詢隊列。
此隊列的默認可見性超時設置爲5分鐘，這是遠遠長於該過程通常需要，因爲這就是我很快就想，如果處理失敗的消息重試。這就是你想要使用可見性超時的方式。
請注意，在標準加工條件下，正常模式過程不需要5分鐘。
試5次後，SQS將刪除主隊列的消息，而是丟棄該消息爲死信隊列（你可以選擇的數量，我設置爲5）。該隊列由存儲消息的單獨進程使用，並提醒我該消息已超過其允許的接收次數，並且從未被刪除 - 表明有毒丸消息或某種未處理的錯誤或慢性失敗狀態。