Suscripciones de extracción

En este documento se ofrece una descripción general de las suscripciones de extracción, su flujo de trabajo y las propiedades asociadas.

En una suscripción de extracción, un cliente suscriptor solicita mensajes al servidor Pub/Sub.

El modo de extracción puede usar una de las dos APIs de servicio: Pull o StreamingPull. Para ejecutar la API elegida, puedes seleccionar una biblioteca de cliente de alto nivel proporcionada por Google o una biblioteca de cliente de bajo nivel generada automáticamente. También puedes elegir entre el procesamiento de mensajes asíncrono y síncrono.

Antes de empezar

Antes de leer este documento, asegúrate de que conoces los siguientes conceptos:

  • Cómo funciona Pub/Sub y los diferentes términos de Pub/Sub.

  • Los diferentes tipos de suscripciones que admite Pub/Sub y los motivos por los que puedes usar una suscripción de extracción.

Flujo de trabajo de la suscripción de extracción

En el caso de una suscripción de extracción, el cliente suscriptor inicia las solicitudes a un servidor de Pub/Sub para recuperar los mensajes. El cliente suscriptor usa una de las siguientes APIs:

La mayoría de los clientes de suscriptores no hacen estas solicitudes directamente. En su lugar, los clientes utilizan la biblioteca de cliente de alto nivel proporcionada por Google Cloud, que realiza solicitudes de extracción de streaming internamente y envía mensajes de forma asíncrona. Para un cliente suscriptor que necesite más control sobre cómo se extraen los mensajes, Pub/Sub usa una biblioteca gRPC de bajo nivel y generada automáticamente. Esta biblioteca hace solicitudes de extracción o de extracción de streaming directamente. Estas solicitudes pueden ser síncronas o asíncronas.

En las dos imágenes siguientes se muestra el flujo de trabajo entre un cliente de suscriptor y una suscripción de extracción.

Flujo de mensajes de una suscripción de extracción
Imagen 1. Flujo de trabajo de una suscripción de extracción



Flujo de mensajes de una suscripción StreamingPull
Imagen 2. Flujo de trabajo de una suscripción de extracción de streaming

Flujo de trabajo de extracción

El flujo de trabajo de extracción es el siguiente (consulta la figura 1):

  1. El cliente suscriptor llama explícitamente al método pull, que solicita mensajes para enviarlos. Esta solicitud es la PullRequest, tal como se muestra en la imagen.

  2. El servidor de Pub/Sub responde con cero o más mensajes y IDs de confirmación. Una respuesta con cero mensajes o con un error no indica necesariamente que no haya mensajes disponibles para recibir. Esta respuesta es el PullResponse que se muestra en la imagen.

  3. El cliente suscriptor llama explícitamente al método acknowledge. El cliente usa el ID de confirmación devuelto para confirmar que el mensaje se ha procesado y no es necesario volver a enviarlo.

En una única solicitud de extracción de streaming, un cliente suscriptor puede recibir varias respuestas debido a la conexión abierta. Por el contrario, solo se devuelve una respuesta por cada solicitud de extracción.

Propiedades de una suscripción de extracción

Las propiedades que configures en una suscripción de extracción determinan cómo escribes mensajes en la suscripción. Para obtener más información, consulta las propiedades de suscripción.

APIs de servicio de Pub/Sub

La suscripción de extracción de Pub/Sub puede usar una de las dos APIs siguientes para obtener mensajes:

  • Extraer
  • StreamingPull

Usa las RPCs unarias Acknowledge y ModifyAckDeadline cuando recibas mensajes con estas APIs. Las dos APIs de Pub/Sub se describen en las siguientes secciones.

API StreamingPull

Cuando es posible, las bibliotecas de cliente de Pub/Sub usan StreamingPull para conseguir el máximo rendimiento y la latencia más baja. Aunque es posible que nunca uses la API StreamingPull directamente, es importante que sepas en qué se diferencia de la API Pull.

La API StreamingPull se basa en una conexión bidireccional persistente para recibir varios mensajes a medida que estén disponibles. Este es el flujo de trabajo:

  1. El cliente envía una solicitud al servidor para establecer una conexión. Si se supera la cuota de conexiones, el servidor devuelve un error de recursos agotados. La biblioteca de cliente vuelve a intentar realizar la solicitud automáticamente si se produce un error por haber superado la cuota.

  2. Si no hay ningún error o la cuota de conexión vuelve a estar disponible, el servidor envía mensajes continuamente al cliente conectado.

  3. Si se supera la cuota de rendimiento, el servidor dejará de enviar mensajes. Sin embargo, la conexión no se interrumpe. Cuando vuelva a haber suficiente cuota de rendimiento disponible, el flujo se reanudará.

  4. El cliente o el servidor cierran la conexión.

La API StreamingPull mantiene una conexión abierta. Los servidores de Pub/Sub cierran la conexión de forma recurrente después de un periodo para evitar una conexión persistente de larga duración. La biblioteca de cliente vuelve a abrir automáticamente una conexión StreamingPull.

Los mensajes se envían a la conexión cuando están disponibles. Por lo tanto, la API StreamingPull minimiza la latencia y maximiza el rendimiento de los mensajes.

Consulta más información sobre los métodos RPC StreamingPull: StreamingPullRequest y StreamingPullResponse.

API Pull

Esta API es un RPC unario tradicional que se basa en un modelo de solicitud y respuesta. Una sola respuesta de extracción se corresponde con una sola solicitud de extracción. Este es el flujo de trabajo:

  1. El cliente envía una solicitud al servidor para obtener mensajes. Si se supera la cuota de rendimiento, el servidor devuelve un error de recursos agotados.

  2. Si no hay ningún error o la cuota de capacidad de procesamiento vuelve a estar disponible, el servidor responde con cero o más mensajes e IDs de confirmación.

Cuando se usa la API Pull unaria, una respuesta con cero mensajes o con un error no indica necesariamente que no haya mensajes disponibles para recibir.

El uso de la API Pull no garantiza una latencia baja ni un rendimiento alto de los mensajes. Para conseguir un alto rendimiento y una baja latencia con la API Pull, debes tener varias solicitudes pendientes simultáneas. Las solicitudes nuevas se crean cuando se responde a las antiguas. Diseñar una solución de este tipo es un proceso propenso a errores y difícil de mantener. Te recomendamos que utilices la API StreamingPull en estos casos.

Usa la API Pull en lugar de la API StreamingPull solo si necesitas un control estricto sobre lo siguiente:

  • Número de mensajes que puede procesar el cliente suscriptor.
  • Memoria y recursos del cliente

También puedes usar esta API cuando tu suscriptor sea un proxy entre Pub/Sub y otro servicio que funcione de forma más orientada a la extracción.

Consulta más información sobre los métodos REST de extracción: Método: projects.subscriptions.pull.

Consulta más información sobre los métodos Pull RPC: PullRequest y PullResponse.

Tipos de modos de procesamiento de mensajes

Elige uno de los siguientes modos de extracción para tus clientes suscriptores.

Modo de extracción asíncrono

El modo de extracción asíncrono desacopla la recepción de mensajes del procesamiento de mensajes en un cliente suscriptor. Este modo es el predeterminado para la mayoría de los clientes de suscriptor. El modo de extracción asíncrono puede usar la API StreamingPull o la API Pull unaria. La extracción asíncrona también puede usar la biblioteca de cliente de alto nivel o la biblioteca de cliente de bajo nivel generada automáticamente.

Puedes consultar más información sobre las bibliotecas de cliente más adelante en este documento.

Modo de extracción síncrono

En el modo de extracción síncrono, la recepción y el procesamiento de los mensajes se producen en secuencia y no están desacoplados entre sí. Por lo tanto, al igual que ocurre con las APIs StreamingPull y Pull unarias, el procesamiento asíncrono ofrece una latencia menor y un mayor rendimiento que el procesamiento síncrono.

Usa el modo de extracción síncrono solo en aplicaciones en las que la latencia baja y el rendimiento alto no sean los factores más importantes en comparación con otros requisitos. Por ejemplo, una aplicación puede estar limitada a usar solo el modelo de programación síncrono. También puede que una aplicación con restricciones de recursos necesite un control más exacto sobre la memoria, la red o la CPU. En estos casos, usa el modo síncrono con la API Pull unaria.

Bibliotecas de cliente de Pub/Sub

Pub/Sub ofrece una biblioteca de cliente de alto nivel y otra de bajo nivel generadas automáticamente.

Biblioteca de cliente de Pub/Sub de alto nivel

La biblioteca de cliente de alto nivel ofrece opciones para controlar los plazos de confirmación mediante la gestión de concesiones. Estas opciones son más detalladas que cuando configuras los plazos de confirmación mediante la consola o la CLI a nivel de suscripción. La biblioteca de cliente de alto nivel también implementa la compatibilidad con funciones como la entrega ordenada, la entrega exactamente una vez y el control de flujo.

Recomendamos usar la extracción asíncrona y la API StreamingPull con la biblioteca de cliente de alto nivel. No todos los idiomas que se admiten enGoogle Cloud también admiten la API Pull en la biblioteca de cliente de alto nivel.

Para usar las bibliotecas de cliente de alto nivel, consulta Bibliotecas de cliente de Pub/Sub.

Biblioteca de cliente de Pub/Sub de nivel bajo generada automáticamente.

Hay disponible una biblioteca de cliente de nivel inferior para los casos en los que debes usar la API Pull directamente. Puedes usar el procesamiento síncrono o asíncrono con la biblioteca de cliente de bajo nivel generada automáticamente. Debes codificar manualmente funciones como la entrega ordenada, la entrega exactamente una vez, el control de flujo y la gestión de concesiones cuando usas la biblioteca de cliente de bajo nivel generada automáticamente.

Puedes usar el modelo de procesamiento síncrono cuando utilices la biblioteca de cliente de bajo nivel generada automáticamente para todos los idiomas admitidos. Puedes usar la biblioteca de cliente de bajo nivel generada automáticamente y la extracción síncrona en los casos en los que tenga sentido usar la API Pull directamente. Por ejemplo, puede que tengas una lógica de aplicación que dependa de este modelo.

Para usar directamente las bibliotecas de cliente de nivel inferior generadas automáticamente, consulta la descripción general de las APIs de Pub/Sub.

Siguientes pasos