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

En la publicación, un cliente editor envía un mensaje a un tema de Pub/Sub. Aquí tienes algunas prácticas recomendadas para publicar mensajes en Pub/Sub.

En este documento se da por hecho que ya conoces el proceso de publicación de mensajes en un tema de Pub/Sub.

Si no has usado Pub/Sub antes, consulta una de las guías de inicio rápido y descubre cómo ejecutar Pub/Sub con la consola, la CLI de gcloud o las bibliotecas de cliente.

Tomar medidas en función de la respuesta de la publicación

Cuando se completa la llamada de publicación de la biblioteca de cliente de alto nivel, devuelve un objeto futuro que contiene el resultado de la operación. Para evitar que se bloqueen solicitudes de publicación individuales, gestiona el resultado de forma asíncrona. Debes decidir cuál es la mejor forma de gestionar el error en tu caso práctico. Aquí te ofrecemos algunas opciones:

  • Registra el error y no hagas nada más (si tu caso práctico no requiere que se publiquen todos los mensajes correctamente).
  • Vuelve a intentar la publicación si se produce un error potencialmente transitorio, como un error Deadline exceeded.
  • Persiste el mensaje en un archivo o almacenamiento para volver a publicarlo más tarde, sobre todo si se produce un error que requiere la intervención del usuario, como Not found o Permission denied.
  • Propaga los errores al servicio upstream que te envió el mensaje que intentaste publicar.

Si crees que Pub/Sub no está enviando mensajes a tus suscriptores como debería, comprueba que estás monitorizando los resultados de las publicaciones y que estas se han realizado correctamente.

Adjunta una suscripción o habilita la conservación de temas antes de empezar a publicar

Si empiezas a publicar en un tema que no tiene ningún suscriptor asociado, los mensajes no se conservarán. Estos mensajes no se pueden enviar a las suscripciones que se adjunten posteriormente. Por lo tanto, antes de empezar a publicar mensajes, haz una de las siguientes acciones:

Configurar el envío de mensajes en lote

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 de cliente para publicar tus mensajes, el procesamiento por lotes está habilitado de forma predeterminada. La agrupación de mensajes ayuda al editor a mejorar su eficiencia y a enviar mensajes con un mayor rendimiento. El procesamiento por lotes reduce el coste de publicar datos. Sin embargo, el procesamiento por lotes también crea latencia para los mensajes individuales, ya que el editor espera a que se llene el lote antes de publicarlo.

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

  • La latencia de extremo a extremo es el tiempo que tarda un editor en publicar un mensaje y en entregarlo a los suscriptores correspondientes para que lo procesen.

  • La latencia de publicación es el tiempo que se tarda en publicar un mensaje.

Cuando se usa el procesamiento por lotes, el aumento de ambos tipos de latencia es un equilibrio para mejorar la eficiencia y el rendimiento.

Puedes agrupar mensajes en una biblioteca de cliente en función del tamaño de la solicitud de mensaje, el número de mensajes y el tiempo. Al configurar los ajustes de lote, puede encontrar el equilibrio adecuado entre coste, rendimiento y latencia para adaptarlos a su caso práctico.

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

Para configurar la mensajería por lotes en un cliente editor, consulta Mensajes por lotes en una solicitud de publicación.

Configurar el control de flujo para picos de mensajes transitorios

Si el cliente del editor tiene que procesar un gran número de mensajes, es posible que las solicitudes de publicación empiecen a acumularse en la memoria hasta que los mensajes no se puedan publicar y se produzca un error Deadline exceeded.

Para hacer frente a los picos transitorios en la publicación de mensajes, puede usar el control del flujo en la configuración de su editor. El control de flujo del lado del editor evita que los recursos del cliente del editor se vean sobrecargados con demasiadas solicitudes pendientes. Si el cliente editor tiene limitaciones de memoria, CPU o subprocesos, se generará un gran número de errores Deadline exceeded.

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

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

Conocer el ancho de banda y la latencia de tu red

El rendimiento de su editor está limitado por el ancho de banda de su red y el número de solicitudes enviadas. Si tu ancho de banda es bueno, pero la latencia de tu red es alta, no te conviene abrumar al sistema con muchas solicitudes pequeñas. El control de flujo del lado del editor puede ayudar a solucionar problemas de red del lado del cliente.

El rendimiento de tu editor también está limitado por la CPU y la memoria. Cuantos más núcleos de máquina tengas disponibles, mayor será el número de subprocesos que podrás definir para mejorar el rendimiento de publicación. Para obtener más información sobre cómo maximizar el rendimiento del streaming, consulta Probar clientes de Cloud Pub/Sub para maximizar el rendimiento del streaming.

Ajustar las variables de la solicitud de reintento de las publicaciones fallidas

Cuando un cliente editor publica un mensaje, es posible que se produzcan errores de publicación. Estos fallos suelen deberse a cuellos de botella del lado del cliente, como CPUs de servicio insuficientes, un estado incorrecto de los hilos o congestión de la red. El parámetro publisher retry policy determina el comportamiento en caso de que falle la entrega del mensaje. La política de reintentos define el número de veces que Pub/Sub intenta entregar el mensaje y el tiempo que transcurre entre cada intento.

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

  • initialRetryDelay. El retraso inicial que espera el editor antes de volver a intentar una operación de publicación. El valor predeterminado es 100 milliseconds.

  • retryDelayMultiplier. Factor de multiplicación usado 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 en el segundo reintento y de hasta 400 milliseconds * 4 = 1600 milliseconds en el tercero.

  • maxRetryDelay. El retraso máximo que espera el editor antes de volver a intentar una operación de publicación. El valor predeterminado es 60 seconds.

  • initialRpcTimeout. Tiempo de espera inicial que espera el editor para que se complete la llamada RPC. El valor predeterminado es 5 seconds.

  • rpcTimeoutMultiplier. Factor de multiplicación usado para calcular el tiempo de espera de la llamada a procedimiento remoto. 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 tercero.

  • maxRpcTimeout. El tiempo de espera máximo que espera el editor para que se complete la llamada RPC. El valor predeterminado es 600 seconds.

  • totalTimeout. Tiempo de espera total de la operación de publicación. Esto incluye el tiempo que se tarda en completar la llamada RPC y el tiempo que se tarda en esperar entre reintentos. El valor predeterminado es 600 seconds.

Solo debes ajustar los valores especificados si consideras que la configuración de reintentos predeterminada no es suficiente para tu caso práctico. Por ejemplo, si publicas un gran número de mensajes, no tendrás que aumentar los valores de initialRetryDelay y maxRetryDelay. Sin embargo, puedes ajustar el control de flujo y el procesamiento por lotes en estas circunstancias. Si publicas contenido con una conexión a Internet inestable o con un ancho de banda limitado, puedes probar con los valores de las variables initialRpcTimeout, maxRpcTimeout y rpcTimeoutMultiplier. Para ver los valores recomendados, consulta Las operaciones de publicación fallan con el error DEADLINE_EXCEEDED.

Usar la política de almacenamiento de mensajes para asegurar la localidad de los datos

La política de almacenamiento de mensajes de temas de Pub/Sub ofrece una forma de asegurarse de que los mensajes publicados en un tema nunca se conserven fuera de un conjunto deGoogle Cloud regiones 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 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 que se procese. La política se puede configurar en un tema o como una política de 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 un tema concreto solo se puede cambiar de formas que no infrinjan 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 asegurarse de que todos los datos se almacenan en regiones de la UE y, de esta forma, cumplir las leyes locales.

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

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

Si usas el orden de los mensajes, asegúrate de que se cumplan los siguientes requisitos:

  • Usa endpoints de ubicación. El orden de los mensajes se conserva en el lado de publicación y en una región. Es decir, si publicas mensajes en varias regiones, solo los mensajes de la misma región se entregarán en un orden coherente. Si todos tus mensajes se publican en la misma región, pero tus suscriptores están repartidos en varias regiones, estos recibirán todos los mensajes en orden. Usa un endpoint de ubicación para publicar mensajes en la misma región.

  • Configura una función para reanudar la publicación. Cuando una biblioteca de cliente vuelve a intentar enviar una solicitud y el mensaje tiene una clave de ordenación, la biblioteca de cliente vuelve a intentar enviar la solicitud repetidamente, independientemente de la configuración de reintentos. Si se produce un error no reintentable, la biblioteca cliente no publica el mensaje y deja de publicar otros mensajes con la misma clave de ordenación. Cuando quieras seguir publicando con una clave de ordenación que haya fallado, llama al método resumePublish.

Resumen de las prácticas recomendadas

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

Tema Tarea
Configurar la conservación de mensajes Adjunta una suscripción antes de publicar o habilitar la conservación de mensajes.
Enviar mensajes por lotes en una solicitud de publicación Agrupa o envía mensajes en lote para aumentar la eficiencia del editor y enviar mensajes con un mayor rendimiento.
Control de flujo Configura el control de flujo en los ajustes del editor para gestionar los picos de tráfico transitorios.
Pruebas de clientes de Pub/Sub para maximizar el rendimiento del streaming Aumenta el rendimiento de los editores incrementando los núcleos de máquina y el ancho de banda de la red disponibles.
Volver a intentar 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 práctico.
Configurar 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 endpoint de ubicación cuando utilices claves de ordenación en la publicación Cuando uses la mensajería ordenada, utiliza un endpoint de ubicación y configura una función de reanudación de la publicación para los errores de publicación.

Siguientes pasos