本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 對 Amazon SQS 無效字母佇列和 DLQ 再驅動問題進行故障診斷
<a name="troubleshooting-dlq-redrive"></a>

下列主題涵蓋 Amazon SQS DLQ 和 DLQ 再驅動問題的最常見原因，以及如何進行故障診斷。如需詳細資訊，請參閱 *AWS 知識中心指南*中的[如何疑難排解 Amazon SQS DLQ 再驅動問題？](https://repost.aws/knowledge-center/sqs-dead-letter-queue-redrive)。

## DLQ 問題
<a name="troubleshooting-dlq-issues"></a>

了解常見的 DLQ 問題以及如何解決這些問題。

### 使用主控台檢視訊息可能會導致訊息被移動至無效字母佇列
<a name="sqs-dlq-console"></a>

Amazon SQS 根據相對應佇列的再驅動政策來計算在主控台中檢視訊息的次數。因此，如果您在主控台中檢視對應佇列再驅動政策中指定的訊息次數，訊息會移至對應佇列的無效字母佇列。

若要調整此行為，可執行以下其中一項：
+ 提高相應佇列的再驅動政策的**最大接收量**設定。
+ 避免在主控台中檢視相對應佇列的訊息。

### 無效字母佇列的 `NumberOfMessagesSent` 和 `NumberOfMessagesReceived` 不相符
<a name="sqs-dlq-number-of-messages"></a>

若您手動將訊息傳送至無效字母佇列，其會由 [`NumberOfMessagesSent`](sqs-available-cloudwatch-metrics.md) 指標擷取。不過，若訊息是因為處理訊息的嘗試失敗而送到無效字母佇列，就不會由此指標擷取。因此， `NumberOfMessagesSent`和 的值可能[`NumberOfMessagesReceived`](sqs-available-cloudwatch-metrics.md)不同。

### 建立和設定無效字母佇列再驅動
<a name="sqs-dlq-redrive-permissions"></a>

無效字母佇列再驅動需要您為 Amazon SQS 設定適當的[許可](sqs-configure-dead-letter-queue-redrive.md#sqs-configure-dead-letter-queue-redrive-permissions)，以接收來自無效字母佇列的訊息，並將訊息傳送到目的地佇列。如果您沒有正確的許可，無效字母佇列再驅動任務可能會失敗。您可以檢視訊息再驅動任務的狀態，以修復問題，然後再試一次。

### 標準和 FIFO 佇列訊息失敗處理
<a name="sqs-dead-letter-queues-handling-message-failure"></a>

[**標準佇列**](standard-queues.md)會持續處理訊息，直到[保留期間](sqs-dead-letter-queues.md#understanding-message-retention-periods)過期為止。這種持續處理可將佇列被未使用的訊息封鎖的機率降至最低。如果消費者重複刪除大量訊息，可能會增加成本，並對硬體施加額外負載。若要降低成本，請將失敗的訊息移至無效字母佇列。

標準佇列也允許大量的傳輸中訊息。如果您大部分的訊息都無法使用，而且未傳送到無效字母佇列，處理訊息的速度可能會變慢。若要維持佇列的效率，請確定您的應用程式正確處理訊息處理。

[**FIFO 佇列**](sqs-fifo-queues.md)可依序消耗訊息群組內的訊息，藉此確保僅會經過恰好一次的處理。因此，雖然消費者可以繼續從另一個訊息群組擷取排序的訊息，但第一個訊息群組仍然無法使用，直到成功處理封鎖佇列的訊息或移至無效字母佇列為止。

此外，FIFO 佇列允許較少數量的傳輸中訊息。若要防止 FIFO 佇列被訊息封鎖，請確定您的應用程式正確處理訊息處理。

如需詳細資訊，請參閱[Amazon SQS 訊息配額](quotas-messages.md)及[Amazon SQS 最佳實務](sqs-best-practices.md)。

## DLQ 重新驅動問題
<a name="troubleshooting-dlq-redrive-issues"></a>

了解常見的 DLQ 重新驅動問題以及如何解決這些問題。

### AccessDenied 許可問題
<a name="accessdenied-permission-issue"></a>

當 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` 錯誤
<a name="nonexistentqueue-error"></a>

當 Amazon SQS 來源佇列不存在或刪除時，就會`NonExistentQueue`發生錯誤。檢查並重新驅動到存在的 Amazon SQS 佇列。

**錯誤訊息範例：**

```
Failed: AWS.SimpleQueueService.NonExistentQueue
```

### CouldNotDetermineMessageSource 錯誤
<a name="couldnotdeterminemessagesource-error"></a>

當您嘗試在下列情況下啟動 DLQ 再驅動時，會發生此`CouldNotDetermineMessageSource`錯誤：
+ 使用 [`SendMessage`](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) API 直接傳送至 DLQ 的 Amazon SQS 訊息。
+ 來自 Amazon Simple Notification Service (Amazon SNS) 主題或 AWS Lambda 函數且已設定 DLQ 的訊息。

若要解決此錯誤，請在啟動**再驅動時選擇再驅動到自訂目的地**。然後，輸入 Amazon SQS 佇列 ARN，將所有訊息從 DLQ 移至目的地佇列。

**錯誤訊息範例：**

```
Failed: CouldNotDetermineMessageSource
```