Descripción general del servicio de Pub/Sub

Pub/Sub es un servicio de publicación y suscripción (Pub/Sub), un servicio de mensajería en el que los remitentes de mensajes están separados de los destinatarios. Hay varios conceptos clave en un servicio de Pub/Sub, que se explican con la ayuda de la siguiente figura.

Figura que muestra los diferentes componentes de un servicio de Pub/Sub y cómo se conectan entre sí.
Figura 1 Dos clientes publicadores envían dos mensajes diferentes a un tema de Pub/Sub común.

A continuación, se indican los componentes de un servicio de Pub/Sub:

  • Publicador (también llamado productor): Crea mensajes y los envía (publica) al servicio de mensajería dentro de un tema específico.

  • Mensaje: Los datos que se mueven a través del servicio

  • Tema: Una entidad denominada que representa un feed de mensajes

  • Esquema: Es una entidad con nombre que rige el formato de datos de un mensaje de Pub/Sub.

  • Suscripción: Es una entidad con nombre que representa un interés en recibir mensajes sobre un tema en particular.

  • Suscriptor (también llamado consumidor): Recibe mensajes de una suscripción específica.

En el siguiente procedimiento, se analiza el flujo de trabajo del servicio de Pub/Sub:

  1. Dos aplicaciones de publicador, Publicador 1 y Publicador 2, envían mensajes a un solo tema de Pub/Sub. El publicador 1 envía el mensaje A y el publicador 2 envía el mensaje B.

  2. El tema en sí está vinculado a dos suscripciones. Estas son Suscripción 1 y Suscripción 2.

  3. El tema también se adjunta a un esquema.

  4. Cada suscripción recibe una copia de los mensajes A y B del tema.

  5. La suscripción 1 está conectada a dos aplicaciones de suscriptores, Suscriptor 1 y Suscriptor 2. Las dos aplicaciones de suscriptor reciben un subconjunto de los mensajes del tema. En este ejemplo, el suscriptor 1 recibe el mensaje B, mientras que el suscriptor 2 recibe el mensaje A del tema.

  6. Subscription 2 solo está conectada a una sola aplicación de suscriptor llamada Subscriber 3. Por lo tanto, el suscriptor 3 recibe todos los mensajes del tema.

Ciclo de vida de un mensaje

Supón que un solo cliente publicador está conectado a un tema. El tema tiene una sola suscripción adjunta. Un solo suscriptor está conectado a la suscripción.

Diagrama que muestra cómo fluye un mensaje dentro de Pub/Sub.
Figura 2 Un mensaje fluye de un cliente publicador a un cliente suscriptor a través de Pub/Sub.

En los siguientes pasos, se describe cómo fluye un mensaje en Pub/Sub:

  1. Una aplicación de publicador envía un mensaje a un tema de Pub/Sub.

  2. El mensaje se escribe en el almacenamiento.

  3. Además de escribir el mensaje en el almacenamiento, Pub/Sub lo entrega a todas las suscripciones adjuntas del tema.

    En este ejemplo, se trata de una sola suscripción.

  4. La suscripción envía el mensaje a una aplicación de suscriptor adjunta.

  5. El suscriptor envía una confirmación a Pub/Sub de que procesó el mensaje.

    Una vez que al menos un suscriptor por cada suscripción confirmó la recepción del mensaje, Pub/Sub borra el mensaje del almacenamiento.

Estado de un mensaje en Pub/Sub

Cuando un mensaje está pendiente para un suscriptor, Pub/Sub no intenta entregarlo a ningún otro suscriptor con la misma suscripción. El suscriptor tiene una cantidad de tiempo limitada y configurable, conocida como ackDeadline, para confirmar la recepción del mensaje pendiente. Una vez transcurrido el plazo, el mensaje ya no se considera pendiente y vuelve a estar disponible para su entrega.

Un mensaje en un servicio de Pub/Sub puede tener tres estados:

  • Mensajes confirmados (acked). Después de que una aplicación del suscriptor procesa un mensaje enviado desde un tema a una suscripción, envía una confirmación de recepción a Pub/Sub. Si todas las suscripciones de un tema confirmaron la recepción del mensaje, este se borra de forma asíncrona de la fuente de mensajes publicados y del almacenamiento.

  • Mensajes no confirmados (unacked). Si Pub/Sub no recibe una confirmación dentro del plazo de confirmación, es posible que un mensaje se entregue más de una vez. Por ejemplo, es posible que el suscriptor envíe una confirmación de recepción después de que venza el plazo o que la confirmación de recepción se pierda debido a problemas de red transitorios. Los mensajes no confirmados se siguen entregando hasta que vence el tiempo de retención de mensajes desde que se publicaron. En este punto, vence el mensaje.

  • Mensajes con confirmación negativa (nacked). Si un suscriptor envía un NACK para un mensaje, Pub/Sub lo volverá a entregar de inmediato según la configuración predeterminada de reintentos, que se puede modificar. Cuando un suscriptor envía un NACK para indicar que los mensajes no son válidos o que no puede procesarlos, ayuda a garantizar que estos mensajes no se pierdan y que se procesen correctamente. Puedes usar modifyAckDeadline con un valor de 0 para enviar un NACK de un mensaje.

Elige un patrón de publicación y suscripción de Pub/Sub

Cuando hay varios clientes de publicadores y suscriptores de Pub/Sub, también debes elegir el tipo de arquitectura de publicación y suscripción que deseas configurar.

Figura que muestra diferentes patrones de publicación y suscripción.
Figura 3 Las relaciones entre el publicador y el suscriptor pueden ser de varios a uno (fan-in), de varios a varios (con equilibrio de carga) y de uno a varios (fan-out).

Estos son algunos de los patrones de publicación y suscripción de Pub/Sub compatibles:

  • Fan in (de varios a uno). En este ejemplo, varias aplicaciones de publicadores publican mensajes en un solo tema. Este único tema está vinculado a una sola suscripción. A su vez, la suscripción se conecta a una sola aplicación de suscriptor que recibe todos los mensajes publicados en el tema.

  • Balanceo de cargas (muchos a muchos): En este ejemplo, una o varias aplicaciones de publicador publican mensajes en un solo tema. Este único tema se adjunta a una sola suscripción que, a su vez, está conectada a varias aplicaciones de suscriptores. Cada una de las aplicaciones de suscriptores recibe un subconjunto de los mensajes publicados, y no hay dos aplicaciones de suscriptores que reciban el mismo subconjunto de mensajes. En este caso de balanceo de cargas, usarás varios suscriptores para procesar mensajes a gran escala. Si se deben admitir más mensajes, agrega más suscriptores para que reciban mensajes de la misma suscripción.

  • Fan out (uno a varios). En este ejemplo, una o varias aplicaciones de publicador publican mensajes en un solo tema. Este único tema está asociado a varias suscripciones. Cada suscripción está conectada a una sola aplicación del suscriptor. Cada una de las aplicaciones de suscriptor recibe el mismo conjunto de mensajes publicados del tema. Cuando un tema tiene varias suscripciones, cada mensaje se debe enviar a un suscriptor que recibe mensajes en nombre de cada suscripción. Si necesitas realizar diferentes operaciones de datos en el mismo conjunto de mensajes, la expansión es una buena opción. También puedes adjuntar varios suscriptores a cada suscripción y obtener un subconjunto de mensajes con balance de carga para cada suscriptor.

Elige una opción de configuración de Pub/Sub

Puedes configurar un entorno de Pub/Sub con cualquiera de las siguientes opciones:

  • Consola deGoogle Cloud
  • Google Cloud CLI
  • Bibliotecas cliente de Cloud (biblioteca cliente de alto nivel)
  • APIs de REST y RPC (biblioteca cliente de bajo nivel)

La opción de configuración de Pub/Sub que elijas dependerá de tu caso de uso.

Si no conoces la consola de Google Cloud y quieres probar Pub/Sub, usa la consola o gcloud CLI.

Se recomienda la biblioteca cliente de alto nivel para los casos en los que se requiere una capacidad de procesamiento alta y una latencia baja con una sobrecarga operativa y un costo de procesamiento mínimos. De forma predeterminada, la biblioteca cliente de alto nivel usa la API de StreamingPull. Las bibliotecas cliente de alto nivel contienen funciones y clases prediseñadas que controlan las llamadas a la API subyacentes para la autenticación, la optimización del rendimiento y la latencia, el formato de mensajes y otras funciones.

La biblioteca cliente de bajo nivel es una biblioteca gRPC generada automáticamente y entra en juego cuando usas las APIs de servicio directamente.

A continuación, se incluyen algunas prácticas recomendadas para usar las bibliotecas cliente:

  • Elige el lenguaje de biblioteca cliente adecuado. El rendimiento de las bibliotecas cliente de Pub/Sub varía según el lenguaje. Por ejemplo, la biblioteca cliente de Java es más eficaz para escalar verticalmente que la biblioteca cliente de Python y puede controlar más rendimiento. Java, C++ y Go son lenguajes más eficientes en términos de los recursos de procesamiento necesarios para controlar las cargas de publicación o suscripción.

  • Usa la versión más reciente de la biblioteca cliente. Las bibliotecas cliente de Pub/Sub se actualizan constantemente con nuevas funciones y correcciones de errores. Asegúrate de usar la versión más reciente de la biblioteca cliente para tu idioma.

  • Reutiliza clientes de publicadores. Cuando publiques mensajes, es más eficiente reutilizar el mismo cliente de publicador en lugar de crear clientes de publicador nuevos para cada solicitud de publicación. Esto se debe a que la primera solicitud de publicación después de crear un cliente de publicador nuevo requiere algo de tiempo para establecer una conexión autorizada. En algunos lenguajes, como Node, que no tienen un cliente de publicador explícito, reutiliza el objeto en el que llamas al método de publicación. Por ejemplo, en Node, guarda y reutiliza el objeto del tema.

Cómo configurar Pub/Sub

Estos son los pasos de alto nivel para configurar Pub/Sub:

  1. Crea o elige un proyecto de Google Cloud en el que puedas configurar Pub/Sub.

  2. Habilita la API de Pub/Sub.

  3. Obtén los roles y permisos necesarios para ejecutar Pub/Sub.

  4. Crea un tema.

  5. Si la estructura del mensaje es fundamental, define un esquema para tus mensajes.

  6. Adjunta el esquema al tema.

  7. Configura un cliente publicador que pueda publicar mensajes en el tema.

  8. Si es necesario, configura opciones de publicación avanzadas, como el control de flujo, la mensajería por lotes y el control de simultaneidad.

  9. Elige un tipo de suscripción según la forma en que quieras recibir mensajes.

  10. Crea una suscripción para el tema elegido.

  11. Configura un cliente suscriptor que pueda recibir mensajes de la suscripción.

  12. Si es necesario, configura opciones avanzadas de entrega de mensajes, como la entrega exactamente una vez, la administración de arrendamientos, la entrega ordenada y el control de flujo.

  13. Comienza a publicar mensajes desde tu cliente publicador en el tema.

  14. Al mismo tiempo, configura tu cliente suscriptor para que reciba y procese estos mensajes.

Lineamientos para asignar nombres a temas, suscripciones, esquemas o instantáneas

Con un nombre de recurso de Pub/Sub, se identifica de forma exclusiva un recurso de Pub/Sub, como un tema, una suscripción, un esquema o una instantánea. El nombre del recurso debe tener el siguiente formato:

projects/project-identifier/collection/ID

  • project-identifier: Debe ser el ID o el número del proyecto, disponible en la consola de Google Cloud . Por ejemplo, my-cool-project es un ID del proyecto. 123456789123 es un número de proyecto.

  • collection: Debe ser uno de los siguientes: topics, subscriptions, schemas o snapshots.

  • ID: Debe cumplir con los siguientes lineamientos:

    • No comenzar con la cadena goog
    • Comenzar con una letra
    • tener entre 3 y 255 caracteres
    • Tener solo los siguientes caracteres: letras [A-Za-z], números [0-9], guiones -, guiones bajos _, puntos ., virgulillas ~, signos más + y signos de porcentaje %

    Puedes usar los caracteres especiales de la lista anterior en nombres de recursos sin codificación de URL. Sin embargo, debes asegurarte de que los demás caracteres especiales estén codificados o decodificados de forma correcta cuando los uses en las URLs. Por ejemplo, mi-tópico es un ID no válido. Sin embargo, mi-t%C3%B3pico es válido. Este formato es importante cuando realizas llamadas a la API de REST.

¿Qué sigue?