這很可能是非常簡單的事情，但由于某種原因，我的 SQS 訊息在可見性超時后不再可用。至少這是我的想法，因為使用 lambda 沒有日志條目表明已觸發任何重試。
我的用例是另一個 lambda 為 SQS 佇列提供 JSON 物體，然后需要轉發。有時要發送的資料太多以至于接收端使用 HTTP 429 進行回應。
我發送的 lambda（通過 HTTPS 的 JSON 正文）僅在服務回應 HTTP 200 時才從佇列中洗掉訊息，否則receiptHandle我認為應該將訊息保留在佇列中。
無論如何，當請求被服務拒絕時，訊息不再可用，因此它永遠不會再次嘗試發送并且永遠丟失。
傳入 SQS 已設定如下：
- 能見度超時：3分鐘
- 交貨延遲：0s
- 接收訊息等待時間：1s
- 訊息保留期：1d
- 最大訊息大小：256Kb
關聯 DLQ 的最大接收數為 100
消費 lambda 配置為
- 記憶體：128Mb
- 超時：10s
- 觸發器：源 SQS 佇列，批處理大小：10，批處理視窗：無
我在 lambda 中的實際邏輯非常簡單，真的。它接收到的事件Records在佇列中。Lambda 一次可能會獲得多條記錄，但所有記錄都是單獨處理的。
console.log('Response', response);
if (response.status === 'CREATED') {
/* some code here */
const deleteParams = {
QueueUrl: queueUrl, /* required */
ReceiptHandle: receiptHandle /* required */
};
console.log('Removing record from ', queueUrl, 'with params', deleteParams);
await sqs.deleteMessage(deleteParams).promise();
} else {
/* any record that ends up here, are never seen again :( */
console.log('Keeping record in', eventSourceARN);
}
做什么 :( ?!?!11
uj5u.com熱心網友回復：
否則我對receiptHandle什么都不做，我認為應該將訊息保留在佇列中
這不，現在它的作業原理：
Lambda 輪詢佇列并與包含佇列訊息的事件同步呼叫您的 Lambda 函式。Lambda 分批讀取訊息并為每個批次呼叫一次您的函式。當您的函式成功處理批處理時，Lambda 會從佇列中洗掉其訊息。
uj5u.com熱心網友回復：
當從 Amazon SQS 佇列觸發 AWS Lambda 函式時，與 SQS 相關的所有活動都由 Lambda 服務處理。您的代碼不應呼叫任何 Amazon SQS 函式。
訊息將通過event引數提供給 AWS Lambda 函式。當函式成功退出時，Lambda 服務將從佇列中洗掉訊息。
您的代碼不應呼叫DeleteMessage().
如果您希望發出某些訊息未成功處理的信號，您可以使用部分批處理回應來指示哪些訊息已成功處理。然后，AWS Lambda 服務將使不成功的訊息再次在佇列中可用。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/416661.html
標籤：