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

# Amazon SQS 中的中斷復原案例
<a name="designing-for-outage-recovery-scenarios"></a>

FIFO 佇列中的重複資料刪除程序分秒必爭。設計應用程式時，請確保生產者和消費者都可以從用戶端或網路中斷中復原，而不會造成重複或處理失敗。

生產者考量事項
+ Amazon SQS 會強制執行 5 分鐘的重複資料刪除時段。
+ 如果生產者在 5 分鐘後重試[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)請求，Amazon SQS 會將其視為新訊息，可能會建立重複項目。

消費者考量事項
+ 如果消費者無法在可見性逾時到期之前處理訊息，另一個消費者可能會接收並處理訊息，導致重複處理。
+ 根據應用程式的處理時間調整可見性逾時。
+ 使用 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html) API 在訊息仍在處理時延長逾時。
+ 如果訊息重複無法處理，請將其路由到[無效字母佇列 (DLQ)](sqs-dead-letter-queues.md)，而不是允許無限期地重新處理。
+ 生產者必須注意到佇列的重複資料刪除間隔。Amazon SQS 的最低重複資料刪除間隔為 5 分鐘。在重複資料刪除間隔過期之後重試 `SendMessage` 請求，可能會將重複的訊息引進佇列中。例如，在汽車中的行動裝置傳送訊息，其順序很重要。如果在收到確認前汽車失去行動連線一段時間，則在重新連上行動連線後重試請求便會建立重複的訊息。
+ 消費者必須擁有可見性逾時，以將可見性逾時過期前無法處理訊息的風險降至最低。訊息正在處理時，您可以呼叫 `ChangeMessageVisibility` 動作來延長可見性逾時。不過，如果可見性逾時已過期，另一個消費者可以立即開始處理訊息，如此會導致多次處理同一則訊息。若要避免這種情況，請設定[無效字母佇列](sqs-dead-letter-queues.md)。