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 para publicar 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, 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 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 la mensajería por lotes

En Pub/Sub, la mensajería por lotes hace referencia 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, la función por lotes está habilitada de forma predeterminada. El procesamiento por lotes (o 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 publicación de datos. Sin embargo, el procesamiento por lotes también crea 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 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 la hora. Cuando configures la configuración por lotes, podrás encontrar el equilibrio adecuado entre el costo, la capacidad de procesamiento y la latencia para tu caso de uso.

Los valores predeterminados de las variables de mensajes 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 mensajes en lotes, la biblioteca cliente publica el siguiente lote de mensajes.

Para configurar los mensajes por lotes para un cliente publicador, consulta Cómo enviar 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 publiquen 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 vean abrumados por 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 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 la red es alta, no debes abrumar al sistema con muchas solicitudes pequeñas. El control de flujo del publicador puede ayudar con los problemas de red del cliente.

La capacidad de procesamiento de tu publicador también está limitada por la CPU y la memoria. Con más núcleos de máquina disponibles, puedes establecer un recuento de subprocesos más alto para mejorar la capacidad de procesamiento de publicación. Para obtener más información sobre 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 fallas de publicación. Por lo general, estas fallas se deben a cuellos de botella del cliente, como CPUs de servicio insuficientes, mal estado del subproceso o congestión en la red. 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 la cantidad de tiempo entre cada intento.

Por ejemplo, en la biblioteca cliente de Java para Pub/Sub, el cliente del 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 los reintentos. El valor predeterminado es 4. Esto significa que la demora entre los 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 de la llamada a RPC es de hasta 5 seconds * 4 = 20 seconds para la segunda 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 para que se complete la llamada a la RPC. El valor predeterminado es 600 seconds.

  • totalTimeout. Es el tiempo de espera total de la operación de publicación. Esto incluye el tiempo que se espera a que se complete la llamada a 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 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 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 Se produce 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 encuentren fuera de un conjunto de regiones de Google Cloud que especifiques, sin importar de dónde se generen 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 proyectos o una organización completa. 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 para cumplir con las leyes locales.

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

Prácticas recomendadas para los mensajes ordenados en la publicación

Si usas el orden de los mensajes, asegúrate de 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 distribuyen 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 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 tengas todo listo para continuar publicando en una clave de ordenamiento que no se pudo publicar, 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.
Cómo enviar 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 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.
Probar 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 la máquina disponibles y el ancho de banda de red.
Cómo reintentar solicitudes Realiza ajustes en 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 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 los mensajes ordenados, 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?