Prácticas recomendadas para publicar en un tema de Pub/Sub

Durante la publicación, un cliente publicador envía un mensaje a un tema de Pub/Sub. Estas son algunas prácticas recomendadas para publicar mensajes en Pub/Sub.

En este documento, se supone que ya estás familiarizado con el proceso de publicación de mensajes en un tema de Pub/Sub.

Si recién comienzas a usar Pub/Sub, consulta una de las guías de inicio rápido y aprende a ejecutar Pub/Sub mediante Console, gcloud CLI o las bibliotecas cliente.

Adjunta una suscripción o habilita la retención de temas antes de comenzar a publicar

Si comienzas a publicar en un tema que no tiene un suscriptor conectado, los mensajes no se retienen. Estos mensajes no se pueden entregar a las suscripciones adjuntas posteriores. Por lo tanto, antes de comenzar a publicar mensajes, realiza una de las siguientes acciones:

Adjuntar una suscripción a un tema Elige uno de los siguientes métodos:
- Crea una suscripción y especifica un tema durante el proceso. Aprende a crear una suscripción de extracción, una suscripción push, una suscripción a BigQuery o una suscripción a Cloud Storage.
- Selecciona una suscripción predeterminada cuando crees un tema.
Habilita la retención de mensajes por temas.

La retención de mensajes por tema permite que una suscripción vuelva a reproducir los mensajes que se publicaron antes de que crearas una suscripción. Si la retención de mensajes de temas está habilitada, los costos de almacenamiento de los mensajes retenidos por el tema se facturan al proyecto en el que se encuentra el tema.

Configura los mensajes por lotes

En Pub/Sub, la mensajería por lotes se refiere al proceso de combinar varios mensajes en un lote que se publica en una sola solicitud de publicación. Si usas bibliotecas cliente para publicar tus mensajes, el procesamiento en lotes estará habilitado de forma predeterminada. El procesamiento por lotes (o agrupación) de los mensajes ayuda al publicador a mejorar su eficiencia y a enviar mensajes con una capacidad de procesamiento mayor. La agrupación en lotes reduce el costo de publicar datos. Sin embargo, el procesamiento en lotes también crea latencia para los mensajes individuales porque el publicador espera a que el lote se llene antes de publicarlo.

La latencia en Pub/Sub puede ser de dos tipos:

La latencia de extremo a extremo es el tiempo que tarda un publicador en publicar un mensaje y entregarlo a los suscriptores correspondientes para su procesamiento.
La latencia de publicación es la cantidad de tiempo que tarda en publicarse un mensaje.

Cuando se usa el procesamiento por lotes, aumentar ambos tipos de latencias es una compensación para mejorar la eficiencia y la capacidad de procesamiento.

Puedes agrupar los mensajes en una biblioteca cliente según el tamaño de la solicitud de mensaje, la cantidad de mensajes y el tiempo. Cuando establezcas la configuración por lotes, podrás encontrar el equilibrio adecuado entre costo, capacidad de procesamiento y latencia para tu caso de uso.

Los valores predeterminados de las variables de mensajes por lotes y los nombres de las variables pueden variar entre las bibliotecas cliente. Puedes especificar uno o los tres valores en la biblioteca cliente. Si se cumple cualquiera de los valores para las variables de mensajes por lotes, la biblioteca cliente publica el siguiente lote de mensajes.

Si deseas configurar la mensajería por lotes para un cliente publicador, consulta Mensajes por lotes en una solicitud de publicación.

Configura el control de flujo para los aumentos repentinos de mensajes transitorios

Si el cliente publicador tiene que procesar una gran cantidad de mensajes, las solicitudes de publicación pueden comenzar a acumularse en la memoria hasta que los mensajes no se publiquen con un error Deadline exceeded.

Para abordar los aumentos repentinos en la publicación de mensajes, puedes usar el control de flujo en la configuración del publicador. El control de flujo del publicador evita que los recursos del cliente del publicador se abrumen con demasiadas solicitudes pendientes. Si el cliente publicador se ve restringido en términos de memoria, CPU o subprocesos, se genera una gran cantidad de errores Deadline exceeded.

Si deseas configurar el control de flujo en la biblioteca cliente, establece los valores adecuados para la cantidad máxima de mensajes pendientes y la cantidad máxima de bytes de mensajes pendientes. Estos valores equilibran la capacidad de procesamiento de mensajes y del sistema.

Para verificar si tu biblioteca cliente es compatible con el control de flujo del publicador y configurarlo, consulta Control de flujo.

Comprende la latencia y el ancho de banda de tu red

La capacidad de procesamiento del publicador está limitada por el ancho de banda de tu red y la cantidad de solicitudes enviadas. Si tu ancho de banda es bueno, pero la latencia de red es alta, no querrás abrumar el sistema con muchas solicitudes pequeñas. El control de flujo del editor puede ayudar con los problemas de red del cliente.

La capacidad de procesamiento del publicador también depende de la CPU y la memoria. Con más núcleos de máquina disponibles, puedes establecer una mayor cantidad de subprocesos para mejorar la capacidad de procesamiento de publicación. Si deseas comprender mejor cómo maximizar el rendimiento de la transmisión, consulta Prueba los clientes de Cloud Pub/Sub para maximizar el rendimiento de la transmisión.

Ajusta las variables de solicitud de reintento para publicaciones con errores

Cuando un cliente publicador publica un mensaje, es posible que veas errores de publicación. Por lo general, estas fallas se deben a cuellos de botella del cliente, como CPU de servicio insuficientes, mal estado de los subprocesos o la congestión de la red. La publisher retry policy determina el comportamiento en caso de que falle la entrega de mensajes. La política de reintentos define la cantidad de veces que Pub/Sub intenta entregar el mensaje y el tiempo entre cada intento.

Por ejemplo, en la biblioteca cliente de Java para Pub/Sub, el cliente publicador contiene los siguientes valores:

initialRetryDelay. Es el retraso inicial que espera el publicador antes de reintentar una operación de publicación. El valor predeterminado es 100 milliseconds.
retryDelayMultiplier. El factor de multiplicación que se usa para calcular el retraso entre reintentos. El valor predeterminado es 4. Esto significa que el retraso entre reintentos es de hasta 100 milliseconds * 4 = 400 milliseconds para el segundo reintento y de hasta 400 milliseconds * 4 = 1600 milliseconds para el tercer reintento.
maxRetryDelay. El retraso máximo que espera el publicador antes de reintentar una operación de publicación. El valor predeterminado es 60 seconds.
initialRpcTimeout. El tiempo de espera inicial que el editor espera a que se complete la llamada RPC. El valor predeterminado es 5 seconds.
rpcTimeoutMultiplier. El factor de multiplicación que se usa para calcular el tiempo de espera de RPC. El valor predeterminado es 4.0. Esto significa que el tiempo de espera de la llamada RPC es de hasta 5 seconds * 4 = 20 seconds para el segundo reintento y de hasta 10 seconds * 4 = 40 seconds para el tercer reintento.
maxRpcTimeout. El tiempo de espera máximo que el publicador espera para que se complete la llamada RPC. El valor predeterminado es 600 seconds.
totalTiempo de espera. El tiempo de espera total para la operación de publicación. Esto incluye el tiempo dedicado a esperar a que se complete la llamada RPC y el tiempo transcurrido entre los reintentos. El valor predeterminado es 600 seconds.

Solo realiza ajustes en los valores especificados si crees que la configuración de reintento predeterminada no es suficiente para tu caso de uso. Por ejemplo, publicar una gran cantidad de mensajes no requiere que aumentes los valores initialRetryDelay ni maxRetryDelay. Sin embargo, puedes ajustar el control de flujo y la agrupación en lotes en esas circunstancias. Si publicas desde una conexión a Internet inestable o con limitaciones de ancho de banda, puedes experimentar con los valores de las variables initialRpcTimeout, maxRpcTimeout y rpcTimeoutMultiplier. Para consultar los valores recomendados, consulta Las operaciones de publicación fallan con DEADLINE_EXCEEDED.

Usa la política de almacenamiento de mensajes para garantizar la localidad de los datos

La política de almacenamiento de mensajes por temas de Pub/Sub ofrece una manera de garantizar que los mensajes publicados en un tema nunca persistan fuera de un conjunto de regiones de Google Cloud que especifiques, independientemente de dónde se originen las solicitudes de publicación.

Usa la política de almacenamiento de mensajes para especificar una lista de regiones de Google Cloud en las que Pub/Sub puede almacenar datos de mensajes en el disco. Cuando se publica un mensaje en una región que no está en esta lista, la solicitud se reenvía a la región permitida más cercana para su procesamiento. La política se puede configurar en un tema o como una política de la organización para un proyecto, una carpeta de proyecto o toda una organización. Cuando se configura una política de la organización, la política de tema individual se puede cambiar solo de formas que no infrinjan la política de la organización.

Por ejemplo, una empresa que opera en Europa podría usar la política de almacenamiento de mensajes para asegurarse de que todos los datos se almacenen en regiones de la UE para cumplir con las leyes locales.

Para obtener más información, consulta Configura políticas de almacenamiento de mensajes.

Prácticas recomendadas para la publicación de mensajes ordenados

Si usas el ordenamiento de los mensajes, asegúrate de que se cumpla lo siguiente:

Usa extremos de ubicación. El orden de los mensajes se conserva en el lado de la publicación y dentro de una región. En otras palabras, si publicas mensajes en varias regiones, solo los mensajes dentro de la misma región se entregan en un orden coherente. Si todos tus mensajes están publicados en la misma región, pero los suscriptores están repartidos entre regiones, los suscriptores reciben todos los mensajes en orden. Usa un extremo de ubicación para publicar mensajes en la misma región.
Configura una función de reanudación de publicación. Cuando una biblioteca cliente vuelve a intentar una solicitud y el mensaje tiene una clave de ordenamiento, la biblioteca cliente vuelve a intentar la solicitud de forma reiterada, independientemente de la configuración de reintento. Si se produce un error que no se puede reintentar, la biblioteca cliente no publica el mensaje y deja de publicar otros mensajes con la misma clave de ordenamiento. Cuando esté todo listo para continuar publicando en una clave de pedido que tiene una publicación con errores, llama al método resumePublish.

Resumen de prácticas recomendadas

En la siguiente tabla, se resumen las prácticas recomendadas en este documento:

Tema	Tarea
Configura la retención de mensajes	Adjunta una suscripción antes de publicar o habilitar la retención de mensajes.
Mensajes por lotes en una solicitud de publicación	Mensajes por lotes o grupales para aumentar la eficiencia del publicador y enviar mensajes con una capacidad de procesamiento mayor.
Control de flujo	Establece el control de flujo en la configuración del publicador para controlar los aumentos de tráfico transitorios.
Prueba los clientes de Pub/Sub para maximizar el rendimiento de la transmisión	Escala la capacidad de procesamiento del publicador con un aumento en los núcleos de máquina disponibles y el ancho de banda de red.
Solicitudes de reintento	Realiza ajustes a los valores especificados de la política de reintentos del publicador solo si consideras que la configuración predeterminada no es suficiente para tu caso de uso.
Configura políticas de almacenamiento de mensajes	Usa la política de almacenamiento de mensajes para almacenar datos de mensajes en el disco solo en ubicaciones específicas.
Usa un extremo de ubicación cuando uses claves de ordenamiento en la publicación	Cuando uses mensajes ordenados, usa un extremo local y configura una función de reanudación de la publicación para errores de publicación.