Suscripciones de inserción

En este documento, se proporciona una descripción general de una suscripción de envío, su flujo de trabajo y las propiedades asociadas.

En la entrega de envío, Pub/Sub inicia solicitudes a tu aplicación de suscriptor para entregar mensajes. Los mensajes se entregan a un servidor direccionable de forma pública o a un webhook, como una solicitud HTTPS POST.

Las suscripciones de envío minimizan las dependencias de las bibliotecas cliente y los mecanismos de autenticación específicos de Pub/Sub. También funcionan bien con tecnologías de servicio sin servidores y con ajuste de escala automático, como Cloud Functions, Cloud Run y Google Kubernetes Engine.

Antes de comenzar

Antes de leer este documento, asegúrate de estar familiarizado con lo siguiente:

Flujo de trabajo de la suscripción de envío

En una suscripción de envío, un servidor de Pub/Sub inicia una solicitud a tu cliente suscriptor para que entregue mensajes.

En la siguiente imagen, se muestra el flujo de trabajo entre un cliente suscriptor y una suscripción de envío.

Flujo de mensajes para una suscripción de envío
Figura 3: Flujo de trabajo para una suscripción de envío

A continuación, se incluye una breve descripción del flujo de trabajo que hace referencia a la Figura 3:

  1. El servidor de Pub/Sub envía cada mensaje como una solicitud HTTPS al cliente suscriptor en un extremo preconfigurado. Esta solicitud se muestra como un PushRequest en la imagen.
  2. El extremo confirma el mensaje cuando muestra un código de estado de éxito HTTP. Una respuesta no exitosa indica que Pub/Sub debe volver a enviar los mensajes. Esta respuesta se muestra como un PushResponse en la imagen.
  3. Pub/Sub ajusta la frecuencia de solicitudes de envío de forma dinámica en función de la frecuencia con la que recibe respuestas exitosas.

Propiedades de una suscripción de envío

Las propiedades que configuras para una suscripción de envío determinan cómo escribes los mensajes en la suscripción. Para obtener más información, consulta las propiedades de suscripción.

Cómo reciben los mensajes los extremos de envío

Cuando Pub/Sub entrega un mensaje a un extremo de envío, puedes elegir enviarlo unido o separado. De forma predeterminada, los mensajes se envían unidos.

  • Envuelta. Pub/Sub envía el mensaje en el cuerpo JSON de una solicitud POST.
  • Se desencapsuló. Pub/Sub envía los datos del mensaje sin procesar directamente como el cuerpo HTTP.

En los siguientes ejemplos, se muestra un cuerpo unido de una solicitud POST JSON a un extremo de envío que contiene la string Hello there en el campo message.data

El cuerpo de una solicitud POST es un objeto JSON. Los datos del mensaje se encuentran en el campo message.data y están codificados en base64.

Ejemplo de una solicitud con los valores mínimos

  {
      "message": {
          "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
          "messageId": "2070443601311540",
          "message_id": "2070443601311540",
          "publishTime": "2021-02-26T19:13:55.749Z",
          "publish_time": "2021-02-26T19:13:55.749Z"
      },
    "subscription": "projects/myproject/subscriptions/mysubscription"
  }

Ejemplo de una solicitud con los valores máximos

Ten en cuenta que este ejemplo muestra los valores máximos actuales, que pueden cambiar con el tiempo. Además, el mapa de atributos puede contener una variedad de valores.

  {
      "deliveryAttempt": 5,
      "message": {
          "attributes": {
              "key": "value"
          },
          "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
          "messageId": "2070443601311540",
          "message_id": "2070443601311540",
          "orderingKey": "key",
          "publishTime": "2021-02-26T19:13:55.749Z",
          "publish_time": "2021-02-26T19:13:55.749Z"
      },
    "subscription": "projects/myproject/subscriptions/mysubscription"
}

Para recibir mensajes de suscripciones de envío, usa un webhook y procesa las solicitudes POST que Pub/Sub envía al extremo de envío. Para obtener más información sobre cómo procesar estas solicitudes POST en App Engine, consulta Escribe y responde mensajes de Pub/Sub.

Después de recibir una solicitud de envío, muestra un código de estado HTTP. Para confirmar el mensaje, muestra uno de los siguientes códigos de estado:

  • 102
  • 200
  • 201
  • 202
  • 204

Para enviar una confirmación negativa del mensaje, muestra cualquier otro código de estado. Si envías una confirmación negativa o se vence el plazo de confirmación, Pub/Sub vuelve a enviar el mensaje. No puedes modificar la fecha límite de confirmación de recepción de los mensajes individuales que recibes de las suscripciones de envío.

Autenticación para suscripciones de envío

Si una suscripción de envío usa autenticación, el servicio de Pub/Sub firma un JWT y lo envía en el encabezado de autorización de la solicitud de envío.

Si quieres obtener más información para configurar la autenticación, consulta Autentica solicitudes de envío.

Detén y reanuda la entrega de mensajes

Para evitar por un tiempo que Pub/Sub envíe solicitudes al extremo de envío, cambia la suscripción a extracción. El cambio puede tardar varios minutos en aplicarse.

Para restablecer la entrega de envío, vuelve a configurar la URL en un extremo válido. Para detener la entrega de forma permanente, borra la suscripción.

Retirada de envío

Si un suscriptor de envío envía demasiadas confirmaciones negativas, es posible que Pub/Sub comience a entregar mensajes mediante una retirada de envío. Cuando Pub/Sub usa una retirada push, deja de entregar mensajes durante un período predeterminado. Este intervalo de tiempo puede variar entre 100 milisegundos y 60 segundos. Una vez transcurrido ese tiempo, Pub/Sub comenzará a entregar mensajes nuevamente.

La retirada de push usa un algoritmo de retirada exponencial para determinar la demora de Pub/Sub que usa entre el envío de mensajes. Esta cantidad de tiempo se calcula según la cantidad de confirmaciones negativas que envían los suscriptores.

Por ejemplo, si un suscriptor de envío recibe cinco mensajes por segundo y envía una confirmación negativa por segundo, Pub/Sub entrega mensajes aproximadamente cada 500 milisegundos. O bien, si el suscriptor de envío envía cinco confirmaciones negativas por segundo, Pub/Sub entrega mensajes cada 30 a 60 segundos.

Ten en cuenta las siguientes consideraciones sobre la retirada de rechazo:

  • No se puede activar ni desactivar la retirada push. Tampoco puedes modificar los valores utilizados para calcular el retraso.
  • Envía activadores de retirada en las siguientes acciones:
    • Cuando se recibe una confirmación negativa.
    • Cuando vence la fecha límite de confirmación de recepción de un mensaje.
  • La retirada push se aplica a todos los mensajes de una suscripción (global).

Frecuencia de envío

Pub/Sub ajusta la cantidad de solicitudes de envío simultáneas mediante un algoritmo de inicio lento. La cantidad máxima permitida de solicitudes de envío simultáneas es la ventana de envío. El período de envío aumenta en cualquier entrega exitosa y disminuye en caso de fallas. El sistema comienza con un tamaño de ventana pequeño de un solo dígito.

Cuando un suscriptor confirma la recepción de un mensaje, la ventana aumenta de manera exponencial. En el caso de las suscripciones en las que los suscriptores confirman más del 99% de los mensajes y promedian menos de un segundo de latencia de solicitudes push, la ventana de envío debe expandirse lo suficiente como para mantenerse al día con cualquier capacidad de procesamiento de publicación.

La latencia de la solicitud de envío incluye lo siguiente:

Después de 3,000 mensajes pendientes por región, la ventana aumenta de forma lineal para evitar que el extremo de envío reciba demasiados mensajes. Si la latencia promedio supera un segundo o el suscriptor confirma menos del 99% de las solicitudes, el período disminuye al límite inferior de 3,000 mensajes pendientes.

Si quieres obtener más información sobre las métricas que puedes usar para supervisar la entrega de envío, consulta Supervisa las suscripciones de envío.

Cuotas y límites

Las suscripciones de envío están sujetas a un conjunto de quotas y límites de recursos.

¿Qué sigue?