重试事件

Eventarc 的重试特征与其传输层 Cloud Pub/Sub 的重试特征一致。如需了解详情，请参阅重试请求和推送退避算法。

Eventarc 设置的默认消息保留时长为 24 小时，具有指数退避算法延迟。

您可以通过与 Eventarc 触发器关联的 Pub/Sub 订阅更新重试政策：

  1. 打开“触发器详细信息”页面。
  2. 点击主题。
  3. 点击订阅标签页。

Eventarc 自动创建的任何订阅都将采用以下格式：projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID。如需详细了解订阅限制，请参阅 Pub/Sub 资源限制。

如果 Pub/Sub 尝试传送消息，但目的地无法确认消息，Pub/Sub 将至少以 10 秒的指数退避算法再次发送消息。如果目的地仍然不确认消息，则每次重试都会增加更多时间（直到最多 600 秒），并将消息重新发送到目的地。

请注意，Workflows 会在工作流执行开始后立即确认事件。

死信主题

如果目的地未收到消息，您可以将未传送的消息转发到死信主题（也称为死信队列）。死信主题可以存储目的地无法确认的消息。您必须在创建或更新 Pub/Sub 订阅时设置死信主题，而不是在创建 Pub/Sub 主题时或 Eventarc 创建 Pub/Sub 主题时。如需了解详情，请参阅处理消息故障。

无法保证重试的错误

如果应用使用 Pub/Sub 作为事件来源且未传送事件，则系统会自动重试事件，但无法保证能够重试的错误除外。如果工作流未执行，则不会重试从任何来源到该工作流目的地的事件。如果工作流执行开始但后来失败，则不会重试执行。如需解决此类服务问题，您应在工作流中处理错误和重试。

重复事件

重复事件可能会传送到事件处理程序。根据 CloudEvents 规范，source 和 id 属性的组合被视为唯一，因此任何具有相同组合的事件被视为重复事件。作为一般最佳实践，您应该实现幂等事件处理程序。

使事件处理脚本具有幂等性

可重试的事件处理脚本应遵循以下一般准则，以确保幂等性：

  • 许多外部 API 允许您提供幂等键作为参数。如果您在使用此类 API，应将事件 ID 作为幂等键。
  • 幂等性与“至少一次”机制非常契合，因为它能确保重试的安全性。通常情况下，幂等性对于重试来说是不可或缺的。
  • 确保代码具有内在的幂等性。例如：
    • 确保即使发生多次变更 (mutation)，执行结果也不会改变。
    • 在事务中，先查询数据库状态再更改状态。
    • 确保所有副作用本身也具有幂等性。
  • 在服务之外强制执行事务检查（不依赖代码）。 例如，在某个位置留存状态信息，并记录已处理事件的 ID。
  • 处理重复的带外调用。例如，设置一个单独的清理进程，在发生重复调用后执行清理。