如何解決對 Amazon SQS 佇列發出 API 呼叫時發生的 QueueDoesNotExist 錯誤?

2 分的閱讀內容
0

我對 Amazon Simple Queue Service (Amazon SQS) 佇列發出了 API 呼叫,但收到「QueueDoesNotExist」錯誤。

解決方法

某些 Amazon SQS API 呼叫 (例如 GetQueueAttributesSendMessageDeleteMessage) 可能會造成 QueueDoesNotExist 錯誤。若要針對此錯誤進行疑難排解,請按照下列步驟操作。

確認佇列 URL 正確

確認請求中提供的佇列 URL 正確且不含錯字。

**重要:**如果目的地佇列類型是先進先出 (FIFO),則必須將 .fifo 尾碼附加至佇列 URL。

設定正確的區域

向不正確的 AWS 區域發出請求時,收到 QueueDoesNotExist 錯誤。SDK 和 AWS Command Line Interface (AWS CLI) 無法從佇列 URL 取得目的地區域。相反,用戶端組態會設定區域。

在進行 API 呼叫之前,請在 Amazon SQS 用戶端上設定正確的區域。檢閱 Amazon SQS 用戶端組態,確認您在用戶端上設定了正確的區域。未在用戶端上設定區域時,SDK 或 AWS CLI 會從組態檔或環境變數中選擇區域。SDK 在組態檔中找不到區域時,SDK 預設會將區域設為 us-east-1

如需詳細資訊,請參閱 AWS 區域組態和憑證檔案設定

如果 AWS CloudTrail 支援失敗的 API 呼叫,請檢查 AWS 帳戶中的所有區域是否有失敗的 Amazon SQS 操作。這有助於確定該區域是否為問題的原因。

您也可以在 SDK 或 AWS CLI 上啟動偵錯日誌,以檢查請求的區域。偵錯日誌會顯示請求的目的地主機,例如: 主機:sqs.us-east-1.amazonaws.com。

這些是額外的偵錯日誌資源:

**注意:**若要驗證區域、帳戶或佇列名稱,請確保記錄完整佇列詳細資料。

檢查最近刪除的佇列

最近刪除佇列時,您可能會收到 QueueDoesNotExist 錯誤。識別失敗 API 呼叫的時間戳記,然後在發生錯誤時檢查 CloudTrail 是否有任何 PurgeQueue 操作。訊息刪除程序最多需要 60 秒。

當佇列是 AWS CloudFormation 或其他部署堆疊的一部分且佇列已刪除時,也可能發生此錯誤。堆疊更新或刪除可能會導致佇列遭到刪除並重新建立。如果您在刪除時對佇列發出 API 呼叫,則請求可能會失敗。在發生錯誤時,檢查 CloudTrail 是否有任何 DeleteQueue 操作。

指定使用 GetQueueUrl 時的目的地佇列帳戶號碼

對於 API 呼叫,SDK 或 AWS CLI 通常會從佇列 URL 取得目的地佇列帳戶號碼。不過,GetQueueUrl API 呼叫不會在請求中提供佇列的帳戶,因此預設會針對呼叫者帳戶發出請求。

如果請求是用於跨帳戶佇列,則您必須將目的地佇列帳戶號碼指定為 API 呼叫 QueueOwnerAWSAccountId 參數。

刪除在逾時時間段內移至 DLQ 的訊息

對於使用無效字母佇列 (DLQ) 設定的標準 SQS 佇列,會在重試後將訊息移至 DLQ。將訊息移至 DLQ 之後,當您使用舊的 ReceiptHandle 從主佇列執行 DeleteMessage 操作時,可能會發生 QueueDoesNotExist 錯誤。您必須在設定的 VisibilityTimeout 時間段內刪除訊息。

確保請求者具有所需的 IAM 許可

如果請求的 AWS 身分和存取管理 (IAM) 使用者或角色沒有必要的許可,則您可能會收到下列錯誤訊息: 「指定的佇列不存在,或者您無法存取它。」

使用 GetCallerIdentity API 呼叫來確認 IAM 實體具有必要的許可。

Boto3 Python 中的 GetCallerIdentity API 呼叫範例:

import boto3
sts = boto3.client('sts')
print(sts.get_caller_identity())

例如 Amazon SQS 政策,請參閱 Amazon SQS 政策的基本範例

如需 Amazon SQS 許可的詳細資訊,請參閱存取 Amazon SQS 佇列需要哪些許可?

使用 AWS Support 疑難排解

如果上述疑難排解步驟無法解決您的問題,請聯絡 AWS Support。包含要 RequestId 以及使用失敗 API 呼叫之時區timestamp

AWS 官方
AWS 官方已更新 5 個月前