¿Qué es Pub/Sub?

Pub/Sub es un servicio de mensajería asíncrono que separa los servicios que producen eventos de los que procesan eventos.

Puede usar Pub/Sub como middleware orientado a la mensajería o la transferencia y entrega de eventos para las canalizaciones de estadísticas de transmisión.

Pub/Sub ofrece almacenamiento duradero de mensajes y entrega de mensajes en tiempo real con alta disponibilidad y rendimiento uniforme a gran escala. Los servidores de Pub/Sub se ejecutan en todas las regiones de Google Cloud de todo el mundo.

Para comenzar de inmediato, prueba la Guía de inicio rápido de Cloud Console. Para obtener una introducción más completa, consulta la página sobre cómo compilar un sistema de Pub/Sub operativo.

Conceptos básicos

  • Tema: Un recurso con nombre al que los publicadores envían mensajes
  • Suscripción: Un recurso con nombre que representa la transmisión de mensajes de un único tema específico que se deben entregar a la aplicación suscripta. Para obtener más detalles sobre la semántica de entrega de mensajes y las suscripciones, consulta la guía para suscriptores
  • Mensaje: La combinación de datos y atributos (opcionales) que un publicador envía a un tema y se entrega por último a los suscriptores
  • Atributo de mensaje: Un par clave-valor que un publicador puede definir para un mensaje. Por ejemplo, la clave iana.org/language_tag y el valor en se podrían agregar a los mensajes para indicar que un suscriptor de habla inglesa puede leerlo

Relaciones entre el publicador y el suscriptor

Una aplicación de publicador crea y envía mensajes a un tema. Las aplicaciones de suscriptor crean una suscripción a un tema para recibir mensajes de él. La comunicación puede ser de uno a varios (fan-out), de varios a uno (fan-in) y de varios a varios.

El flujo de mensajes de Pub/Sub

La siguiente es una descripción general de los componentes del sistema de Pub/Sub y cómo fluyen los mensajes entre ellos:

  1. Una aplicación de publicador crea un tema en el servicio de Pub/Sub y envía mensajes al tema. Un mensaje contiene una carga útil y atributos opcionales que describen el contenido de la carga.
  2. El servicio garantiza que los mensajes publicados se retengan en nombre de las suscripciones. Un mensaje publicado se retiene para una suscripción hasta que lo confirme cualquier suscriptor que consuma mensajes de esa suscripción.
  3. Pub/Sub reenvía mensajes de un tema a todas sus suscripciones de forma individual.
  4. Un suscriptor recibe mensajes de Pub/Sub empujándolos al extremo elegido por el suscriptor o por el suscriptor extrayéndolos del servicio.
  5. El suscriptor envía una confirmación al servicio de Pub/Sub por cada mensaje recibido.
  6. El servicio quita los mensajes confirmados de la cola de mensajes de la suscripción.

Extremos del publicador y del suscriptor

Los publicadores pueden ser cualquier aplicación que pueda realizar solicitudes HTTPS a pubsub.googleapis.com: una aplicación de App Engine, un servicio web alojado en Google Compute Engine o cualquier otra red de terceros, una aplicación instalada en una computadora de escritorio, un dispositivo móvil un navegador.

Cualquier aplicación que pueda realizar solicitudes HTTPS a googleapis.com puede ser también suscriptor.

Los suscriptores de envíos deben ser extremos de webhook que puedan aceptar solicitudes POST a través de HTTPS.

Casos prácticos habituales

  • Balanceo de cargas de trabajo en clústeres de red. Por ejemplo, una gran cola de tareas se puede distribuir de forma eficiente entre varios trabajadores, como las instancias de Google Compute Engine.
  • Implementación de flujos de trabajo asíncronos. Por ejemplo, una aplicación de procesamiento de pedidos puede colocar un pedido en un tema, desde el cual uno o más trabajadores pueden procesarlo.
  • Distribución de notificaciones de eventos. Por ejemplo, un servicio que acepta registros de usuarios puede enviar notificaciones cada vez que un usuario nuevo se registra, y los servicios descendentes pueden suscribirse para recibir notificaciones del evento.
  • Actualización de cachés distribuidas. Por ejemplo, una aplicación puede publicar eventos de invalidación para actualizar los ID de los objetos que cambiaron.
  • Registro en varios sistemas. Por ejemplo, una instancia de Google Compute Engine puede escribir registros en el sistema de supervisión, en una base de datos para consultas posteriores, etcétera.
  • Transmisión de datos de varios procesos o dispositivos. Por ejemplo, un sensor residencial puede transmitir datos a servidores de backend alojados en la nube.
  • Mejora de la confiabilidad. Por ejemplo, un servicio de Compute Engine de una zona puede operar en zonas adicionales mediante una suscripción a un tema común para recuperarse antes fallas en una zona o región.

Integraciones de Pub/Sub