Descripción general del servicio 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 los mensajes están desacoplados de los destinatarios. En un servicio de Pub/Sub hay varios conceptos clave que se explican con la ayuda de la siguiente figura.

En la figura se muestran los diferentes componentes de un servicio Pub/Sub y cómo se conectan entre sí.
Imagen 1: dos clientes editores envían dos mensajes diferentes a un tema de Pub/Sub común.

Estos son los componentes de un servicio de Pub/Sub:

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

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

  • Tema: una entidad con nombre que representa un feed de mensajes.

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

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

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

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

  1. Dos aplicaciones de editores, Editor 1 y Editor 2, envían mensajes a un único tema de Pub/Sub. Editor 1 envía el mensaje A y Editor 2 envía el mensaje B.

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

  3. El tema también está asociado a un esquema.

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

  5. 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, Suscriptor 1 recibe el mensaje B, mientras que Suscriptor 2 recibe el mensaje A del tema.

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

Tiempo de vida de un mensaje

Supongamos que un solo cliente editor está conectado a un tema. El tema tiene una sola suscripción asociada. Un solo suscriptor está conectado a la suscripción.

Imagen que muestra cómo fluye un mensaje en Pub/Sub.
Imagen 2: Un mensaje fluye de un cliente editor 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 editor 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 envía a todas las suscripciones asociadas al 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 para indicar que ha procesado el mensaje.

    Una vez que al menos un suscriptor de cada suscripción haya confirmado la recepción del mensaje, Pub/Sub eliminará el mensaje del almacenamiento.

Estado de un mensaje en Pub/Sub

Mientras un mensaje esté pendiente para un suscriptor, Pub/Sub no intentará entregarlo a ningún otro suscriptor de la misma suscripción. El suscriptor tiene un tiempo limitado y configurable, conocido como ackDeadline, para confirmar el mensaje pendiente. Una vez que haya pasado la fecha límite, el mensaje dejará de considerarse pendiente y estará disponible para enviarse de nuevo.

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

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

  • Mensajes sin confirmar (unacked). Si Pub/Sub no recibe una confirmación antes de la fecha límite, es posible que un mensaje se entregue más de una vez. Por ejemplo, el suscriptor puede enviar una confirmación después de que haya vencido el plazo o la confirmación puede perderse debido a problemas de red transitorios. Un mensaje sin confirmar se sigue enviando hasta que caduca el periodo de conservación del mensaje desde que se publicó. En ese momento, el mensaje caduca.

  • Mensajes con confirmación negativa (nacked). Si un suscriptor envía una respuesta negativa a un mensaje, Pub/Sub lo volverá a enviar inmediatamente. Cuando un suscriptor envía una respuesta negativa a mensajes no válidos o cuando no puede procesarlos, ayuda a que estos mensajes no se pierdan y a que se procesen correctamente. Puedes usar modifyAckDeadline con el valor 0 para enviar una respuesta negativa a un mensaje.

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

Cuando hay varios clientes de publicación y suscripción de Pub/Sub, también debe elegir el tipo de arquitectura de publicación y suscripción que quiera configurar.

Imagen que muestra diferentes patrones de publicación y suscripción.
Ilustración 3: Las relaciones entre editores y suscriptores pueden ser de muchos a uno (fan-in), de muchos a muchos (con equilibrio de carga) y de uno a muchos (fan-out).

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

  • Fan in (de muchos a uno). En este ejemplo, varias aplicaciones de editores publican mensajes en un solo tema. Este tema está vinculado 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 en el tema.

  • Balanceo de carga (de muchos a muchos). En este ejemplo, una o varias aplicaciones de publicación publican mensajes en un solo tema. Este tema está asociado a una sola suscripción que, a su vez, está conectada a varias aplicaciones de suscriptor. Cada una de las aplicaciones suscriptoras recibe un subconjunto de los mensajes publicados, y no hay dos aplicaciones suscriptoras que reciban el mismo subconjunto de mensajes. En este caso de balanceo de carga, se usan varios suscriptores para procesar mensajes a gran escala. Si necesitas admitir más mensajes, añade más suscriptores para que reciban mensajes de la misma suscripción.

  • Enviar a varios (uno a muchos). En este ejemplo, una o varias aplicaciones de editor publican mensajes en un solo tema. Este tema está vinculado 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 reciba mensajes en nombre de cada suscripción. Si necesitas realizar diferentes operaciones con 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 carga equilibrada 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:

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

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

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

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

La biblioteca de cliente de nivel inferior es una biblioteca gRPC generada automáticamente que se usa cuando se utilizan las APIs de servicio directamente.

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

  • Elige el idioma de la biblioteca de cliente adecuado. El rendimiento de las bibliotecas de cliente de Pub/Sub varía según el lenguaje. Por ejemplo, la biblioteca de cliente de Java es más eficaz para aumentar la escala verticalmente que la biblioteca de cliente de Python y puede gestionar un mayor volumen de datos. Java, C++ y Go son lenguajes más eficientes en cuanto a los recursos de computación necesarios para gestionar las cargas de publicación o suscripción.

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

  • Reutilizar clientes editores. Al publicar mensajes, es más eficiente reutilizar el mismo cliente de editor en lugar de crear clientes de editor nuevos para cada solicitud de publicación. Esto se debe a que la primera solicitud de publicación después de crear un nuevo cliente editor requiere un tiempo para establecer una conexión autorizada. En algunos lenguajes, como Node, que no tienen un cliente de editor explícito, reutiliza 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 generales para configurar Pub/Sub:

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

  2. Habilita la API Pub/Sub.

  3. Obtener los roles y permisos necesarios para ejecutar Pub/Sub.

  4. Crea un tema.

  5. Si la estructura de los mensajes es fundamental, define un esquema para ellos.

  6. Adjunta el esquema al tema.

  7. Configura un cliente editor 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 en función de cómo quieras recibir los mensajes.

  10. Crea una suscripción al tema elegido.

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

  12. Si es necesario, configure opciones avanzadas de entrega de mensajes, como la entrega exactamente una vez, la gestión de concesiones, la entrega ordenada y el control de flujo.

  13. Empieza a publicar mensajes desde tu cliente editor en el tema.

  14. Al mismo tiempo, configura tu cliente de suscriptor para recibir y procesar estos mensajes.

Directrices para asignar un nombre a un tema, una suscripción, un esquema o una captura

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 el número del proyecto, que se puede consultar en la Google Cloud consola. Por ejemplo, my-cool-project es un ID de proyecto. 123456789123 es un número de proyecto.

  • collection: debe ser topics, subscriptions, schemas o snapshots.

  • ID: debe cumplir las siguientes directrices:

    • No empieza por la cadena goog
    • Empieza por una letra
    • Tener entre 3 y 255 caracteres
    • Contener 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 los nombres de recursos sin codificarlos como URL. Sin embargo, debes asegurarte de que los demás caracteres especiales estén codificados o decodificados correctamente cuando los uses en URLs. Por ejemplo, mi-tópico no es un ID válido. Sin embargo, mi-t%C3%B3pico es válido. Este formato es importante cuando haces llamadas REST.

Siguientes pasos