DeliverySpec.RetryAfterMax 字段

标志名称: delivery-retryafter

阶段：Alpha，默认禁用

跟踪问题: #5811

角色：开发者

当使用 delivery spec 配置事件传递参数时，您可以使用 retryAfterMax 字段来指定如何处理 HTTP Retry-After 标头，用于计算重试 429 和 503 响应的退避时间。您可以为 Channels、Subscriptions、Brokers、Triggers 以及任何接受 delivery 字段的其他资源 spec 指定 delivery spec。

retryAfterMax 字段仅在您将 delivery spec 配置为执行重试时生效，并且仅适用于对 429 和 503 响应代码的重试尝试。该字段提供了覆盖，以防止大的 Retry-After 持续时间影响吞吐量，并且必须使用 ISO 8601 格式指定。正常退避持续时间和 Retry-After 标头值中较大的那个将用于后续的重试尝试。指定“零”值 PT0S 会有效地禁用 Retry-After 支持。

在此功能之前，Knative Eventing 实现不支持 Retry-After 标头，这是一个为标准化此支持提供途径的尝试。起初，该功能是 选择加入 的，但最终状态将是 选择退出，如下所示：

功能阶段	功能标志	retryAfterMax 字段不存在	retryAfterMax 字段存在
Alpha / Beta	已禁用	已由 Webhook 验证接受并且未强制执行 Retry-After 标头	已被 WebHook 验证拒绝
Alpha / Beta	已启用	已由 Webhook 验证接受并且未强制执行 Retry-After 标头	已由 Webhook 验证接受并且如果 max 覆盖 > 0，则强制执行 Retry-After 标头
稳定 / GA	不适用	强制执行 Retry-After 标头，无 max 覆盖	如果 max 覆盖 > 0，则强制执行 Retry-After 标头

以下示例显示了一个 Subscription，它将事件重试发送三次，并尊重 Retry-After 标头，同时施加 120 秒的最大退避时间。

apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
  name: example-subscription
  namespace: example-namespace
spec:
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: example-sink
  delivery:
    backoffDelay: PT2S
    backoffPolicy: linear
    retry: 3
    retryAfterMax: PT120S

注意

虽然功能标志通过 Webhook 验证强制执行了 retryAfterMax 字段的所有 DeliverySpec 用法，但它不能保证所有实现（如 Channels 或 Sources）都真正实现了对该字段的支持。共享的 HTTPMessageSender.SendWithRetries() 逻辑已得到增强以支持此功能，所有使用它来执行重试的实现都将自动受益。基于此共享库的扩展实现（例如 RabbitMQ 或 Google Pub/Sub）将需要额外的开发工作来处理 retryAfterMax 字段。