处理投递失败¶

您可以为 Knative Eventing 组件配置事件投递参数，这些参数在事件投递失败的情况下应用

配置订阅事件投递¶

您可以通过在 Subscription 对象中添加 delivery 规范来配置每个订阅的事件投递方式，如以下示例所示

apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
  name: example-subscription
  namespace: example-namespace
spec:
  delivery:
    deadLetterSink:
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: example-sink
    backoffDelay: <duration>
    backoffPolicy: <policy-type>
    retry: <integer>

其中

deadLetterSink 规范包含启用死信队列的配置设置。这会告诉订阅，那些无法投递给订阅者的事件会发生什么。配置此项后，投递失败的事件将发送到死信队列目的地。目的地可以是 Knative Service 或 URI。在此示例中，目的地是一个名为 example-sink 的 Service 对象，即 Knative Service。
backoffDelay 投递参数指定了事件投递失败后重试之前的延迟时间。backoffDelay 参数的持续时间使用 ISO 8601 格式指定。例如，PT1S 指定 1 秒延迟。
backoffPolicy 投递参数可用于指定重试退避策略。策略可以指定为 linear 或 exponential。当使用 linear 退避策略时，退避延迟是重试之间指定的时间间隔。当使用 exponential 退避策略时，退避延迟等于 backoffDelay*2^<numberOfRetries>。
retry 指定在事件发送到死信队列之前重试事件投递的次数。

配置 Broker 事件投递¶

您可以通过添加 delivery 规范来配置每个 Broker 的事件投递方式，如以下示例所示

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: with-dead-letter-sink
spec:
  delivery:
    deadLetterSink:
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: example-sink
    backoffDelay: <duration>
    backoffPolicy: <policy-type>
    retry: <integer>

其中

deadLetterSink 规范包含启用死信队列的配置设置。这会告诉订阅，那些无法投递给订阅者的事件会发生什么。配置此项后，投递失败的事件将发送到死信队列目的地。目的地可以是符合 Knative Eventing sink 契约的任何可寻址对象，例如 Knative Service、Kubernetes Service 或 URI。在此示例中，目的地是一个名为 example-sink 的 Service 对象，即 Knative Service。
backoffDelay 投递参数指定了事件投递失败后重试之前的延迟时间。backoffDelay 参数的持续时间使用 ISO 8601 格式指定。例如，PT1S 指定 1 秒延迟。
backoffPolicy 投递参数可用于指定重试退避策略。策略可以指定为 linear 或 exponential。当使用 linear 退避策略时，退避延迟是重试之间指定的时间间隔。这是一个线性增加的延迟，这意味着退避延迟在每次重试时都会增加给定的间隔。当使用 exponential 退避策略时，退避延迟在每次重试时都会以给定间隔的倍数增加。
retry 指定在事件发送到死信队列之前重试事件投递的次数。初始投递尝试不包括在重试计数中，因此总投递尝试次数等于 retry 值 +1。

Broker 支持¶

下表总结了每种 Broker 实现类型支持的投递参数

Broker 类	支持的投递参数
googlecloud	`deadLetterSink`, `retry`, `backoffPolicy`, `backoffDelay`
Kafka	`deadLetterSink`, `retry`, `backoffPolicy`, `backoffDelay`
MTChannelBasedBroker	取决于底层 Channel
RabbitMQBroker	`deadLetterSink`, `retry`, `backoffPolicy`, `backoffDelay`

注意

deadLetterSink 必须是 GCP Pub/Sub 主题 URI。googlecloud Broker 仅支持 exponential 退避策略。

配置 Channel 事件投递¶

失败的事件，根据所使用的特定 Channel 实现，可能会在转发到 deadLetterSink 之前添加扩展属性。这些扩展属性如下所示

knativeerrordest
- 类型： 字符串
- 描述： 失败事件被发送到的原始目的地 URL。这可能是基于哪个操作遇到失败事件的 delivery 或 reply URL。
- 限制： 始终存在，因为每个 HTTP 请求都有一个目的地 URL。
- 示例
  - "http://myservice.mynamespace.svc.cluster.local:3000/mypath"
  - ...任何 deadLetterSink URL...
knativeerrorcode
- 类型： 整型
- 描述： 最终事件分派尝试的 HTTP 响应 StatusCode。
- 限制： 始终存在，因为每个 HTTP 响应都包含一个 StatusCode。
- 示例
  - "500"
  - ...任何 HTTP StatusCode...
knativeerrordata
- 类型： 字符串
- 描述： 最终事件分派尝试的 HTTP 响应 Body。
- 限制： 如果 HTTP 响应 Body 为空，则为空，如果长度过长，则可能被截断。
- 示例
  - '内部服务器错误：处理事件失败。'
  - '{"key": "value"}'
  - ...任何 HTTP 响应 Body...

Channel 支持¶

下表总结了每种 Channel 实现支持的投递参数。

Channel 类型	支持的投递参数
GCP PubSub	无
内存中	`deadLetterSink`, `retry`, `backoffPolicy`, `backoffDelay`
Kafka	`deadLetterSink`, `retry`, `backoffPolicy`, `backoffDelay`
Natss	无