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.

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 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 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, 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 está vinculado a dos suscripciones. Estas son la suscripción 1 y la 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. La suscripción 2 solo está conectada a una sola aplicación de suscriptor llamada Suscriptor 3. Por lo tanto, el suscriptor 3 recibe todos los mensajes del tema.

Ciclo de vida de un mensaje

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

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, es 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

Mientras 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 el 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 (confirmados). Después de que una aplicación del suscriptor procesa un mensaje que se envía de un tema a una suscripción, envía una confirmación a Pub/Sub. Si todas las suscripciones de un tema confirmaron el mensaje, este se borra de forma asíncrona de la fuente de mensajes publicados y del almacenamiento.

• Mensajes no confirmados (no confirmados): 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 después de que venza el plazo o podría perderse debido a problemas transitorios de red. Un mensaje no confirmado se seguirá enviando hasta que venza el tiempo de retención del mensaje desde que se publicó. En este punto, vence el mensaje.

• Mensajes con acuse de recibo negativo (nacked): Si un suscriptor rechaza un mensaje, Pub/Sub lo vuelve a entregar de inmediato. Cuando un suscriptor rechaza los mensajes no válidos o cuando no puede procesarlos, ayuda a garantizar que no se pierdan y que, en última instancia, se procesen correctamente. Puedes usar modifyAckDeadline con un valor de 0 para rechazar un mensaje.

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

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

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 publicador publican mensajes en un solo tema. Este tema único está vinculado a una sola suscripción. La suscripción, a su vez, está conectada a una sola aplicación de suscriptor que obtiene todos los mensajes publicados del tema.

• Balanceo de cargas (muchos a muchos). En este ejemplo, una o varias aplicaciones de publicador publican mensajes en un solo tema. Este tema único 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, usas 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 tema único está vinculado a varias suscripciones. Cada suscripción está conectada a una sola aplicación de suscriptor. Cada una de las aplicaciones de suscriptor obtiene 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, el fan-out es una buena opción. También puedes adjuntar varios suscriptores a cada suscripción y obtener un subconjunto de mensajes equilibrado de la 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 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 opción de configuración de Pub/Sub que elijas depende de tu caso de uso.

Si es la primera vez que usas 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 alta capacidad de procesamiento y una 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 precompiladas que controlan las llamadas a la API subyacentes para la autenticación, la optimización de la productividad 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.

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

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

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

• Elige el idioma correcto 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 eficaz para escalar verticalmente que la biblioteca cliente de Python y puede manejar más rendimiento. 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 nuevas funciones y correcciones de errores. Asegúrate de usar la versión más reciente de la biblioteca cliente para tu idioma.

• Reutiliza los clientes del publicador. Cuando publicas 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 nuevo cliente de publicador requiere un tiempo para establecer una conexión autorizada. En algunos lenguajes, como Node, que no tienen un cliente 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 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. 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 de los mensajes 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 control de flujo, mensajería por lotes y control de simultaneidad.

9. Elige un tipo de suscripción según cómo quieras 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 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 un nombre a un tema, una suscripción, un esquema o una instantánea

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 de 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
  • 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 los 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 REST.

¿Qué sigue?

• Para comenzar a configurar Pub/Sub con gcloud CLI, consulta la Guía de inicio rápido: Publica y recibe mensajes en Pub/Sub con la CLI de gcloud.

• Para comenzar a configurar Pub/Sub con la consola de Google Cloud, consulta la Guía de inicio rápido: Publica y recibe mensajes en Pub/Sub con la consola de Google Cloud.

• Para comenzar a configurar Pub/Sub con las bibliotecas cliente, consulta la Guía de inicio rápido: Publica y recibe mensajes en Pub/Sub con la biblioteca cliente.