Descripción general del servicio de Pub/Sub

Pub/Sub es un publish/subscribe de publish/subscribe (publish/subscribe), un servicio de mensajería en el que los remitentes de mensajes están separados de los destinatarios. Existen varios conceptos clave de 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 común de Pub/Sub.

Los siguientes son 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 sobre 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: una entidad denominada que rige el formato de datos de un mensaje de Pub/Sub.

  • Suscripción: Una entidad denominada 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, Publisher 1 y Publisher 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. Estos 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 suscriptor, suscriptor 1 y suscriptor 2. Las dos aplicaciones de suscriptor reciben un subconjunto de los mensajes del tema. En este ejemplo, Suscriptores 1 recibe el mensaje B mientras que Suscriptor 2 recibe el mensaje A del tema.

  6. La Suscripción 2 solo está conectada a una aplicación de suscriptor única llamada Suscriptor 3. Por lo tanto, Subscriber 3 recibe todos los mensajes del tema.

Ciclo de vida de un mensaje en Pub/Sub

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

Figura que muestra cómo fluye un mensaje dentro de Pub/Sub.
Figura 2: Un mensaje fluye desde 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 entrega el mensaje a todas las suscripciones adjuntas del tema.

    En este ejemplo, es una suscripción única.

  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 se procesó el mensaje.

    Después de que al menos un suscriptor por cada suscripción confirme la recepción del mensaje, Pub/Sub borra el mensaje del almacenamiento.

Estado de un mensaje en Pub/Sub

Mientras un mensaje está pendiente para un suscriptor, Pub/Sub intenta no 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 el mensaje pendiente. Una vez transcurrido el plazo, el mensaje ya no se considera pendiente, y Pub/Sub intenta volver a entregarlo.

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

  • Mensajes confirmados (confirmados): Después de que una aplicación de 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 el mensaje, este se borra de forma asíncrona de la fuente del mensaje de publicación y del almacenamiento.

  • Mensajes no confirmados (sin confirmación). 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, el suscriptor podría enviar una confirmación de recepción después de que venza el plazo o la confirmación podría perderse debido a problemas transitorios de la red. Un mensaje no confirmado se continúa entregando hasta que el tiempo de retención de mensajes vence desde que se publicó. En este punto, el mensaje vence.

  • Mensajes confirmados de forma negativa (con credenciales). Cuando un suscriptor busca un mensaje, Pub/Sub vuelve a entregarlo de inmediato. Cuando un suscriptor busca mensajes que no son válidos o no puede procesarlos, ayuda a garantizar que estos mensajes no se pierdan y que, finalmente, se procesen de forma correcta. Puedes usar modifyAckDeadline con un valor de 0 para marcar un mensaje.

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

Cuando hay varios clientes de publicador y suscriptor, 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 (balanceo de cargas) y de uno a varios (fan-out).

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

  • Con ventilador, entrada (varios a uno). En este ejemplo, varias aplicaciones de publicador publican mensajes en un solo tema. Este tema se vincula a una sola suscripción. A su vez, la suscripción está conectada a una sola aplicación de suscriptor que recibe todos los mensajes publicados del tema.

  • Carga balanceada (varios a varios). En este ejemplo, una o varias aplicaciones de publicador publican mensajes en un solo tema. Este tema se vincula a una sola suscripción que, a su vez, está conectada a varias aplicaciones de suscriptor. Cada una de las aplicaciones de suscriptor recibe un subconjunto de los mensajes publicados, y ninguna de las dos aplicaciones de suscriptor recibe el mismo subconjunto de mensajes. En este caso de balanceo de cargas, usas varios suscriptores para procesar mensajes a gran escala. Si se deben admitir más mensajes, agregarás más suscriptores para que reciban mensajes de la misma suscripción.

  • Ventilación (de uno a varios). En este ejemplo, una o varias aplicaciones de publicador publican mensajes en un solo tema. Este tema único se conecta a varias suscripciones. Cada suscripción está conectada a una sola aplicación de 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 distribución es una buena opción. También puedes adjuntar varios suscriptores a cada suscripción y obtener un subconjunto de mensajes con balanceo de cargas para cada suscriptor.

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

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

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

La elección de una opción de configuración de Pub/Sub depende de tu caso de uso.

Si es la primera vez que usas la consola de Google Cloud y deseas probar Pub/Sub, usa la consola o gcloud CLI.

Se recomienda la biblioteca cliente de alto nivel para los casos en los que necesites una capacidad de procesamiento alta y baja latencia 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 compiladas previamente que controlan las llamadas a la API subyacentes para la autenticación, la optimización de la capacidad de procesamiento y la latencia, el formato de los mensajes y otras funciones.

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

Las siguientes son algunas prácticas recomendadas para usar las bibliotecas cliente:

  • Elige el idioma adecuado de la biblioteca cliente. 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 efectiva para escalar verticalmente que la biblioteca cliente de Python y puede manejar una mayor capacidad de procesamiento. Java, C++ y Go son lenguajes más eficientes en términos de 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 funciones nuevas y correcciones de errores. Asegúrate de usar la versión más reciente de la biblioteca cliente para tu lenguaje.

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

Cómo configurar Pub/Sub

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

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

  2. Habilitar 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 ellos.

  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 cómo quieres recibir los 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 las 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. De forma simultánea, configura tu cliente suscriptor para recibir y procesar estos mensajes.

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

Un nombre de recurso de Pub/Sub identifica de forma única 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 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 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
    • Contiene 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 correctamente codificados o decodificados cuando los uses en las URLs. Por ejemplo, mi-tópico es un ID no válido. Sin embargo, mi-t%C3%B3pico sí es válido. Este formato es importante cuando realizas llamadas de REST.

¿Qué sigue?