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 conoces el proceso de publicación de mensajes en un tema de Pub/Sub.

Si no conoces Pub/Sub, consulta una de las guías de inicio rápido y aprende a ejecutar Pub/Sub con la consola, la CLI de gcloud o las bibliotecas cliente.

Toma medidas según la respuesta de la publicación

Cuando se completa la llamada de publicación de la biblioteca cliente de alto nivel, se muestra un objeto futuro que contiene el resultado de la operación. Para evitar bloquear solicitudes de publicación individuales, controla el resultado de forma asíncrona. Debes decidir la mejor manera de controlar la falla para tu caso de uso. Estas son algunas opciones:

  • Registra el error y no hagas nada más (si tu caso de uso no requiere que se publiquen todos los mensajes correctamente).
  • Vuelve a intentar la publicación en caso de una falla potencialmente transitoria, como un error Deadline exceeded.
  • Persiste el mensaje en un archivo o almacenamiento para reintentar su publicación más tarde, especialmente en un error que requiere la intervención del usuario, como Not found o Permission denied.
  • Propaga los errores al servicio ascendente que te envió el mensaje que intentaste publicar.

Si crees que Pub/Sub no entrega mensajes a tus suscriptores como se espera, verifica que estés haciendo un seguimiento de los resultados de las publicaciones y que estas se hayan realizado correctamente.

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 adjunto, los mensajes no se retendrán. Estos mensajes no se pueden entregar a las suscripciones adjuntas posteriormente. Por lo tanto, antes de comenzar a publicar mensajes, haz una de las siguientes acciones:

Configura la mensajería 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 por lotes está habilitado de forma predeterminada. El procesamiento por lotes (o la agrupación) de mensajes ayuda al editor a mejorar su eficiencia y enviar mensajes con una mayor capacidad de procesamiento. El procesamiento por lotes reduce el costo de publicar datos. Sin embargo, el procesamiento por lotes también genera latencia para los mensajes individuales, ya que el publicador espera a que se llene el lote 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 mensaje en publicarse por un publicador y entregarse a los suscriptores correspondientes para su procesamiento.

  • La latencia de publicación es la cantidad de tiempo que lleva publicar 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 mensajes en una biblioteca cliente según el tamaño de la solicitud de mensaje, la cantidad de mensajes y el tiempo. Cuando configures los parámetros de configuración de lotes, podrás encontrar el equilibrio adecuado entre el costo, la capacidad de procesamiento y la latencia para que se adapten a tu caso de uso.

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

Para configurar los mensajes por lotes para un cliente publicador, consulta Envía mensajes por lotes en una solicitud de publicación.

Configura el control de flujo para los aumentos transitorios de mensajes

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

Para abordar los aumentos transitorios 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 sobrecarguen con demasiadas solicitudes pendientes. Si el cliente del publicador se ve limitado en términos de memoria, CPU o subprocesos, se genera una gran cantidad de errores Deadline exceeded.

Para configurar el control de flujo en la biblioteca cliente, establece los valores adecuados para las variables maximum outstanding messages y maximum outstanding message bytes. Estos valores equilibran el rendimiento de los mensajes y la capacidad del sistema.

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

Comprende el ancho de banda y la latencia de tu red

La capacidad de procesamiento de tu 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 la red es alta, no conviene sobrecargar el sistema con muchas solicitudes pequeñas. El control de flujo del publicador puede ayudar con los problemas de red del cliente.

El rendimiento de tu publicador también está limitado por la CPU y la memoria. Tener más núcleos de máquina disponibles te permite establecer un mayor recuento de subprocesos para mejorar la capacidad de procesamiento de publicación. Para 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 las 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 del subproceso o congestión en la red. El parámetro publisher retry policy determina el comportamiento en caso de falla en la entrega de mensajes. La política de reintentos define la cantidad de veces que Pub/Sub intenta entregar el mensaje y el tiempo que transcurre entre cada intento.

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

  • initialRetryDelay. Es la demora inicial que espera el publicador antes de reintentar una operación de publicación. El valor predeterminado es 100 milliseconds.

  • retryDelayMultiplier: Es el factor de multiplicación que se usa para calcular la demora entre reintentos. El valor predeterminado es 4. Esto significa que la demora 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: Es la demora máxima que espera el publicador antes de reintentar una operación de publicación. El valor predeterminado es 60 seconds.

  • initialRpcTimeout: Es el tiempo de espera inicial que el publicador espera a que se complete la llamada RPC. El valor predeterminado es 5 seconds.

  • rpcTimeoutMultiplier: Es 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 para la llamada de 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: Es el tiempo de espera máximo que el publicador espera a que se complete la llamada RPC. El valor predeterminado es 600 seconds.

  • totalTimeout. Es el tiempo de espera total para la operación de publicación. Esto incluye el tiempo que se espera a que se complete la llamada RPC y el tiempo que se espera entre los reintentos. El valor predeterminado es 600 seconds.

Solo realiza ajustes en los valores especificados si consideras que la configuración predeterminada de reintentos no es suficiente para tu caso de uso. Por ejemplo, publicar una gran cantidad de mensajes no requeriría que aumentes los valores de initialRetryDelay y maxRetryDelay. Sin embargo, puedes ajustar el control de flujo y el procesamiento por lotes en esas circunstancias. Si publicas desde una conexión a Internet inestable o con ancho de banda limitado, puedes experimentar con los valores de las variables initialRpcTimeout, maxRpcTimeout y rpcTimeoutMultiplier. Para conocer los valores recomendados, consulta Se produjo un error en las operaciones de publicación 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 de temas de Pub/Sub ofrece una forma de garantizar que los mensajes publicados en un tema nunca se almacenen fuera de un conjunto deGoogle Cloud regiones que especifiques, independientemente de dónde se generen las solicitudes de publicación.

Usa la política de almacenamiento de mensajes para especificar una lista de Google Cloud regiones 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 temas individuales solo se puede cambiar 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 garantizar que todos los datos se almacenen en regiones de la UE y, así, cumplir con las leyes locales.

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

Prácticas recomendadas para la mensajería ordenada en la publicación

Si usas el orden de mensajes, asegúrate de cumplir con lo siguiente:

  • Usa extremos de ubicación. El orden de los mensajes se conserva en el lado de 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 se publican en la misma región, pero tus suscriptores se encuentran en diferentes regiones, los suscriptores recibirán todos los mensajes en orden. Usa un extremo de ubicación para publicar mensajes en la misma región.

  • Configura una función de publicación de currículums. Cuando una biblioteca cliente vuelve a intentar una solicitud y el mensaje tiene una clave de ordenamiento, la biblioteca cliente reintenta la solicitud de forma repetida, 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 quieras continuar publicando con una clave de ordenamiento que haya fallado en la publicación, llama al método resumePublish.

Resumen de prácticas recomendadas

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

Tema Tarea
Configura la retención de mensajes Adjunta una suscripción antes de publicar o habilitar la retención de mensajes.
Agrupa mensajes en lotes en una solicitud de publicación Agrupa o envía mensajes en lotes para aumentar la eficiencia del editor y enviar mensajes con una mayor capacidad de procesamiento.
Control de flujo Configura el control de flujo en la configuración del publicador para controlar los aumentos transitorios del tráfico.
Prueba de clientes de Pub/Sub para maximizar el rendimiento de la transmisión Aumenta la capacidad de procesamiento del publicador con un incremento en los núcleos de la máquina y el ancho de banda de red disponibles.
Reintenta las solicitudes Ajusta los valores especificados de la política de reintentos del editor 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 los datos de los 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 la mensajería ordenada, usa un extremo de ubicación y configura una función de reanudación de la publicación para los errores de publicación.

¿Qué sigue?