重試事件

Eventarc 的重試特性與其傳輸層 Cloud Pub/Sub 相同。詳情請參閱「重試要求」和「延後推送」。

Eventarc 預設的訊息保留時間為 24 小時，並採用指數輪詢延遲。

您可以透過與 Eventarc 觸發條件相關聯的 Pub/Sub 訂閱項目，更新重試政策：

1. 開啟「觸發條件詳細資料」頁面。
2. 按一下主題。
3. 按一下「Subscriptions」(訂閱項目) 分頁標籤。

Eventarc 自動建立的訂閱項目格式如下：projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID。如要進一步瞭解訂閱項目限制，請參閱「Pub/Sub 資源限制」。

如果 Pub/Sub 嘗試傳送訊息，但目的地無法確認，Pub/Sub 會再次傳送訊息，並採用至少 10 秒的指數輪詢策略。如果目的地持續未確認訊息，每次重試時，延遲時間會增加 (最多 600 秒)，且訊息會重新傳送至目的地。

請注意，工作流程會在工作流程執行開始時立即確認事件。

無效信件主題

如果目的地未收到訊息，您可以將未傳送的訊息轉寄至無效信件主題 (也稱為無效信件佇列)。如果目的地無法確認訊息，dead-letter 主題就會儲存這些訊息。建立或更新 Pub/Sub 訂閱項目時，您必須設定死信主題，而不是在建立 Pub/Sub 主題時，或 Eventarc 建立 Pub/Sub 主題時。詳情請參閱「處理訊息傳送失敗」。

不值得重試的錯誤

如果應用程式使用 Pub/Sub 做為事件來源，但事件未傳送成功，系統會自動重試，但若發生錯誤，則無法保證會重試。如果工作流程未執行，系統不會重試將任何來源的事件傳送至工作流程目的地。如果工作流程執行作業開始後失敗，系統不會重試執行作業。如要解決這類服務問題，您應在工作流程中處理錯誤和重試。

重複的活動

系統可能會將重複事件傳送至事件處理常式。根據 CloudEvents 規格，source 和 id 屬性的組合視為不重複，因此任何具有相同組合的事件都會視為重複事件。一般來說，最佳做法是導入等冪事件處理常式。

讓事件處理常式具備冪等性

可重試的事件處理常式應為等冪，並遵循下列一般準則：

• 許多外部 API 都允許您以參數形式提供冪等金鑰。如果您使用這類 API，應將事件 ID 做為等冪鍵。
• 冪等性與「至少傳送一次」的傳送方式搭配使用效果良好，因為這樣重試作業會更安全。因此，撰寫可靠程式碼的一般最佳做法，是將等冪性與重試機制結合。
• 請確保您的程式碼為內部冪等。例如：
  • 請確保異動可發生多次，但結果不會改變。
  • 在變更狀態之前，查詢交易中的資料庫狀態。
  • 確保所有連帶影響本身也是冪等的。
• 在服務外部強制執行交易檢查，與程式碼無關。 舉例來說，您可以將狀態保留在某個位置，記錄特定事件 ID 是否已處理完畢。
• 處理頻外重複呼叫。舉例來說，您可以另外建立清除程序，在重複呼叫後進行清除。