重試事件

活動遭拒的原因有很多，舉例來說，事件接收器服務可能會因中斷而暫時無法使用；服務在處理事件時可能會發生錯誤；或服務資源可能會用盡。這類暫時性錯誤可以重試。

事件也可能無法傳送給事件接收者。舉例來說，事件可能不符合設定的預期結構定義，或事件中介服務可能在事件訊息傳送至最終目的地前失敗。這類情況會導致持續發生錯誤。

暫時性錯誤

Eventarc Advanced 可讓您處理暫時性錯誤。這些暫時性錯誤可以重試，包括下列錯誤代碼：

  • HTTP 408 Request Timeout
  • HTTP 409 Conflict
  • HTTP 429 Too Many Requests
  • HTTP 500 Internal Server Error
  • HTTP 502 Bad Gateway
  • HTTP 503 Service Unavailable
  • HTTP 504 Gateway Time-out

永久性錯誤

與暫時性錯誤不同，持續性錯誤包括：

  • 設定的重試次數用盡時發生的錯誤
  • 事件無法順利傳送至目的地時發生的錯誤
  • 導致錯誤代碼被視為無法重試的錯誤；例如，暫時性錯誤清單以外的錯誤代碼

您可以手動找出並妥善處理持續性錯誤。

重試暫時性錯誤

若作業發生錯誤，但可嘗試再次執行，Eventarc Advanced 會使用指數輪詢延遲來處理這類錯誤。預設重試政策會先延遲一秒，每次嘗試失敗後，延遲時間會加倍 (最多 60 秒，最多嘗試五次)。

您可以使用 Google Cloud 控制台或 gcloud beta eventarc pipelines update 指令變更預設重試政策。

請注意，2 的預設退避係數無法變更。

主控台

  1. 在 Google Cloud 控制台中，依序前往「Eventarc」>「Pipelines」(管道) 頁面。

    前往 Pipelines

  2. 按一下管道名稱。

  3. 在「Pipeline details」(管道詳細資料) 頁面中，按一下「Edit」(編輯)。

  4. 在「Edit pipeline」(編輯管道) 頁面的「Retry policy」(重試政策) 區段中，修改下列欄位：

    • 嘗試次數上限：重試次數，預設為 5 次。可以是任何正實數。如果設為 1，系統不會套用重試政策，只會試著傳送訊息一次。
    • 延遲時間下限 (秒)：初始延遲時間 (以秒為單位)，預設為 1 秒。必須介於 1 至 600 之間。
    • 延遲時間上限 (秒)：延遲時間上限 (以秒為單位)，預設為 60 秒。必須介於 1 至 600 之間。

    您可以將延遲時間下限和上限設為相同值，設定線性退避。

  5. 按一下 [儲存]。

gcloud

gcloud beta eventarc pipelines update PIPELINE_NAME \
    --min-retry-delay=MIN_DELAY \
    --max-retry-delay=MAX_DELAY \
    --max-retry-attempts=MAX_ATTEMPTS

更改下列內容：

  • PIPELINE_NAME：管道的 ID 或完整 ID。
  • MIN_DELAY：初始延遲時間 (以秒為單位)，預設為 1 秒。必須介於 1 至 600 之間。
  • MAX_DELAY：延遲時間上限 (以秒為單位)，預設為 60 秒。必須介於 1 至 600 之間。
  • MAX_ATTEMPTS：重試次數，預設為 5 次。可以是任何正實數。如果設為 1，就不會套用重試政策，只會試著傳送訊息一次。

以下範例會將延遲時間下限和上限設為相同值，藉此設定線性退避：

gcloud beta eventarc pipelines update my-pipeline \
    --min-retry-delay=4 \
    --max-retry-delay=4 \
    --max-retry-attempts=5

封存訊息以處理持續性錯誤

您可以在收到訊息時，將訊息寫入 BigQuery 資料表。這項功能可讓您手動找出持續發生的錯誤，並妥善處理。

以下將概略說明封存活動訊息、找出持續性錯誤，以及重試受影響活動的必要步驟。

  1. 建立匯流排。適當設定匯流排，例如發布 Google 來源的事件。
  2. 建立 Pub/Sub 主題。這個 Pub/Sub 主題將做為管道的目標目的地。
  3. 為 Pub/Sub 主題建立 BigQuery 訂閱項目。BigQuery 訂閱項目是一種匯出訂閱項目，會在收到訊息時，將訊息寫入現有 BigQuery 資料表。或者，您也可以在建立 BigQuery 訂閱項目時建立資料表。

  4. 建立管道和註冊項目，將匯流排 (使用 --cel-match="true") 收到的每則訊息，都傳送至 Pub/Sub 主題。為管道設定重試政策。

    舉例來說，下列指令會建立管道和註冊：

    gcloud beta eventarc pipelines create my-archive-pipeline \
    --destinations=pubsub_topic='my-archive-topic',network_attachment='my-network-attachment' \
    --min-retry-delay=1 \
    --max-retry-delay=20 \
    --max-retry-attempts=6 \
    --location=us-central1

    gcloud beta eventarc enrollments create my-archive-enrollment \
    --cel-match="true" \
    --destination-pipeline=my-archive-pipeline \
    --message-bus=my-message-bus \
    --message-bus-project=my-google-cloud-project \
    --location=us-central1

  5. 將管道記錄檔傳送至其他 BigQuery 資料集。

    您現在應該有兩個不同的 BigQuery 資料集：一個用於儲存 Eventarc Advanced 匯流排接收到的每則訊息，另一個則用於儲存管道記錄。

  6. 如要找出失敗的訊息，請使用查詢陳述式，在 message_uid 欄位中聯結兩個 BigQuery 資料集。

  7. 找出失敗的訊息後，您可以使用 Eventarc Publishing API 再次將訊息發布至匯流排。舉例來說，您可以部署 Cloud Run 服務或工作，從 BigQuery 讀取訊息，然後直接發布訊息至 Eventarc Advanced 匯流排。

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

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

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

後續步驟