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 es la primera vez que usas Pub/Sub, consulta una de las guías de inicio rápido y aprende a ejecutar Pub/Sub con la consola, la gcloud CLI 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 las 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 la publicación correcta de todos los mensajes).
  • Vuelve a intentar la publicación en caso de una falla potencialmente transitoria, como un error Deadline exceeded.
  • Guarda el mensaje en un archivo o almacenamiento para volver a intentar publicarlo más tarde, especialmente en un error que requiera 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 los mensajes como se espera a tus suscriptores, verifica que estés haciendo un seguimiento de los resultados de las publicaciones y que estas se hayan realizado correctamente.

Si la publicación se realiza de forma correcta, el resultado de la llamada de publicación es el ID del mensaje del mensaje publicado.

Conservar los IDs de los mensajes

Para facilitar la solución de problemas, los publicadores y suscriptores deben conservar los IDs de los mensajes publicados. Puedes almacenar el ID de cada mensaje publicado o habilitar el registro de los IDs de mensajes según sea necesario. Conservar los IDs de mensajes facilita la solución de problemas de mensajes duplicados, reintentos de entrega, pérdida de datos y otros problemas comunes. Para obtener más información, consulta Cómo lidiar con duplicados.

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 retienen. 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 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 por lotes está habilitado de forma predeterminada. El procesamiento por lotes (o la agrupación) de mensajes ayuda al publicador 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, la organización por lotes también genera latencia para los mensajes individuales, ya que el publicador espera a que se complete 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 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 se tarda en 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 configuras los parámetros de lotes, puedes 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 variar entre las bibliotecas cliente. Puedes especificar uno o los tres valores en la biblioteca cliente. Si se cumple cualquiera 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 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 podrían comenzar a acumularse en la memoria hasta que los mensajes no se publiquen con un error Deadline exceeded.

Para abordar los aumentos transitorios en los mensajes de publicación, 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 vean abrumados con demasiadas solicitudes pendientes. Si el cliente 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 valores adecuados para las variables máximo de mensajes pendientes y máximo de bytes de mensajes pendientes. Estos valores equilibran la capacidad de procesamiento de 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 red es alta, no querrás abrumar el sistema con muchas solicitudes pequeñas. El control de flujo del lado del publicador puede ayudar con los problemas de red del lado del cliente.

La capacidad de procesamiento de tu publicador también está limitada por la CPU y la memoria. La mayor cantidad de núcleos de máquina disponibles te permite establecer un recuento de subprocesos más alto para mejorar la capacidad de procesamiento de publicación. Para comprender mejor cómo maximizar el rendimiento de la transmisión, consulta Prueba 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 fallas 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 congestión de la red. publisher retry policy determina el comportamiento en caso de que falle la entrega del mensaje. 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 la demora inicial que espera el publicador antes de volver a intentar 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 los 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 tercero.

  • maxRetryDelay. Es la demora máxima que espera el publicador antes de volver a intentar una operación de publicación. El valor predeterminado es 60 seconds.

  • initialRpcTimeout. Es el tiempo de espera inicial que el publicador espera para 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 la RPC. El valor predeterminado es 4.0. Esto significa que el tiempo de espera para 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 tercero.

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

Solo realiza ajustes en los valores especificados si consideras que la configuración de reintentos predeterminada 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 una conexión con ancho de banda limitado, puedes experimentar con los valores de las variables initialRpcTimeout, maxRpcTimeout y rpcTimeoutMultiplier. Para conocer 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 de temas de Pub/Sub ofrece una forma de garantizar que los mensajes publicados en un tema nunca se conserven fuera de un conjunto de regiones deGoogle 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 una organización entera. Cuando se configura una política de la organización, la política de tema individual solo se puede cambiar de manera que no infrinja la política de la organización.

Por ejemplo, una empresa que opera en Europa puede usar la política de almacenamiento de mensajes para garantizar 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 mensajería ordenada en la publicación

Si usas el ordenamiento de mensajes, asegúrate de 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 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 están distribuidos en varias 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 reanudación de publicación. Cuando una biblioteca cliente reintenta una solicitud y el mensaje tiene una clave de orden, la biblioteca cliente reintenta la solicitud de forma repetida, independientemente de la configuración de reintentos. 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 orden. Cuando estés listo para seguir publicando en una clave de ordenamiento 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 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 una solicitud de publicación Agrupa los mensajes por lotes para aumentar la eficiencia del publicador 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 repentinos 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 y el ancho de banda de red disponibles.
Reintenta las solicitudes Realiza ajustes en 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 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?