本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
對 Amazon SQS無效字母佇列和DLQ重新驅動問題進行故障診斷
下列主題涵蓋 Amazon SQSDLQ和DLQ重新驅動問題的最常見原因，以及如何進行故障診斷。如需詳細資訊，請參閱 AWS 知識中心指南 中的如何疑難排解 Amazon SQSDLQ重新驅動問題？
DLQ 問題
了解常見問題DLQ以及如何解決這些問題。
主題
使用主控台檢視訊息可能會導致訊息被移動至無效字母佇列
根據對應佇列的重新驅動政策，Amazon SQS計數在主控台中檢視訊息。因此，如果您在主控台中檢視對應佇列的重新驅動政策中指定的訊息次數，訊息會移至對應佇列的無效字母佇列。
若要調整此行為，可執行以下其中一項：
-
提高相應佇列的再驅動政策的最大接收量設定。
-
避免在主控台中檢視相對應佇列的訊息。
無效字母佇列的 NumberOfMessagesSent 和 NumberOfMessagesReceived 不相符
若您手動將訊息傳送至無效字母佇列，其會由 NumberOfMessagesSent 指標擷取。不過，若訊息是因為處理訊息的嘗試失敗而送到無效字母佇列，就不會由此指標擷取。因此， NumberOfMessagesSent和 的值可能會NumberOfMessagesReceived不同。
建立和設定無效字母佇列重新驅動
死字母佇列重新驅動需要您設定適當的許可SQS，讓 Amazon 從死字母佇列接收訊息，並將訊息傳送至目的地佇列。如果您沒有正確的許可，無效字母佇列重新驅動任務可能會失敗。您可以檢視訊息重新驅動任務的狀態以修復問題，然後再試一次。
標準和FIFO佇列訊息失敗處理
標準佇列會保留處理訊息，直到保留期到期為止。這種持續處理可最大限度地降低未取用訊息封鎖佇列的機會。消費者一再無法刪除的大量訊息可能會增加成本，並對硬體施加額外的負載。若要降低成本，請將失敗的訊息移至無效字母佇列。
標準佇列也允許大量機上訊息。如果無法取用大部分訊息，且未傳送至無效字母佇列，處理訊息的速度可能會變慢。若要維持佇列的效率，請確定您的應用程式正確處理訊息處理。
FIFO 佇列透過依序從訊息群組取用訊息，提供精確的一次處理。因此，雖然消費者可以繼續從另一個訊息群組擷取排序訊息，但第一個訊息群組仍然無法使用，直到成功處理封鎖佇列的訊息或移至無效字母佇列為止。
此外，FIFO佇列允許較少數量的傳輸中訊息。若要防止FIFO佇列被訊息封鎖，請確定您的應用程式正確處理訊息處理。
如需詳細資訊，請參閱 Amazon SQS 訊息配額 和 Amazon SQS 最佳實務。
DLQ- 重新驅動問題
了解常見的 DLQ- 重新驅動問題以及如何解決這些問題。
AccessDenied 許可問題
當DLQ重新驅動失敗，因為 AWS Identity and Access Management （IAM） 實體沒有所需的許可時，AccessDenied就會發生錯誤。
錯誤訊息範例：
Failed to create redrive task. Error code: AccessDenied - Queue Permissions to Redrive.
提出DLQ重新驅動請求需要下列API許可：
若要啟動訊息重新驅動：
-
死字母佇列許可：
-
sqs:StartMessageMoveTask -
sqs:ReceiveMessage -
sqs:DeleteMessage -
sqs:GetQueueAttributes -
kms:Decrypt– 當無效字母佇列或原始來源佇列加密時。
-
-
目的地佇列許可：
-
sqs:SendMessage -
kms:GenerateDataKey– 當目的地佇列加密時。 -
kms:Decrypt– 當目的地佇列加密時。
-
若要取消進行中的訊息重新驅動：
-
死字母佇列許可：
-
sqs:CancelMessageMoveTask -
sqs:ReceiveMessage -
sqs:DeleteMessage -
sqs:GetQueueAttributes -
kms:Decrypt– 當無效字母佇列或原始來源佇列加密時。
-
若要顯示訊息移動狀態：
-
死字母佇列許可：
-
sqs:ListMessageMoveTasks -
sqs:GetQueueAttributes
-
NonExistentQueue 錯誤
當 Amazon SQS來源佇列不存在或已刪除時，NonExistentQueue就會發生錯誤。檢查並重新驅動到存在的 Amazon SQS佇列。
錯誤訊息範例：
Failed: AWS.SimpleQueueService.NonExistentQueue
CouldNotDetermineMessageSource 錯誤
當您嘗試以下列案例啟動DLQ重新驅動時，CouldNotDetermineMessageSource就會發生錯誤：
-
使用 直接傳送至 DLQ的
SendMessageAmazon SQS 訊息API。 -
來自 Amazon Simple Notification Service （Amazon SNS） 主題或 AWS Lambda 函數的訊息，其中已DLQ設定 。
若要解決此錯誤，請在啟動重新驅動時選擇重新驅動至自訂目的地。然後，輸入 Amazon SQS佇列ARN，將所有訊息從 DLQ 移至目的地佇列。
錯誤訊息範例：
Failed: CouldNotDetermineMessageSource
