En este documento, se supone que ya conoces el proceso de suscribirte a un tema de Pub/Sub y recibir mensajes en tu cliente suscriptor.
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, Google Cloud CLI o las bibliotecas cliente.
Elige la suscripción adecuada
Pub/Sub ofrece suscripciones estándar, como las de envío y extracción. Además de las suscripciones estándar, Pub/Sub también ofrece suscripciones de exportación que te permiten almacenar mensajes directamente en un recurso deGoogle Cloud , sin necesidad de usar Dataflow como intermediario. Por ejemplo, las suscripciones de BigQuery almacenan mensajes en una tabla de BigQuery.
Se recomiendan las suscripciones de envío para las siguientes situaciones:
No puedes incluir ningún código en tu aplicación de suscriptor que importe la biblioteca cliente como una dependencia.
El cliente suscriptor no puede realizar ninguna solicitud saliente.
Quieres usar la misma instancia para procesar mensajes de diferentes temas y suscripciones en los que el cliente suscriptor no conoce la lista de suscripciones.
Para casos generales, recomendamos usar la
biblioteca cliente de alto nivel. Si, en cambio,
usas la extracción unaria, no configures
returnImmediately
como true. Establecerlo en true afecta de forma negativa el rendimiento de la extracción.
El campo returnImmediately ya no está disponible.
Para comparar todos los tipos de suscripción y elegir el que mejor se adapte a tus necesidades empresariales, consulta la tabla de comparación de suscripciones de Pub/Sub.
Para obtener información sobre los beneficios de una suscripción de exportación, consulta Cuándo usar una suscripción de exportación.
Procesa los mensajes antes de confirmarlos
De forma predeterminada, Pub/Sub descarta un mensaje de una suscripción después de que se confirma el mensaje. Si no procesas un mensaje antes de enviar una confirmación y el procesamiento falla, el servicio no vuelve a entregar el mensaje. La excepción es cuando configuraste la retención de mensajes confirmados o la retención de temas, y realizas una operación de búsqueda.
Si tienes suscriptores con latencia alta, es posible que debas establecer valores personalizados para el control de flujo y la administración de arrendamientos.
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.
Configura el control de flujo del suscriptor para los aumentos repentinos de tráfico transitorio
El control de flujo del lado del suscriptor te permite evitar que los suscriptores se sobrecarguen con aumentos repentinos de tráfico. Puede dar tiempo para que los mecanismos de ajuste de escala automático respondan a un aumento de la carga o puede distribuir el procesamiento de la carga durante un período más largo. El primer método ahorra latencia, mientras que el segundo ahorra costos.
Para configurar el control de flujo, debes establecer
valores adecuados para maximum outstanding messages y
total outstanding message bytes. Los valores predeterminados de estas variables de control de flujo y los nombres de las variables pueden diferir entre las bibliotecas cliente.
Cantidad máxima de mensajes pendientes define la cantidad máxima de mensajes entregados al cliente para los que Pub/Sub no recibió confirmaciones de recepción ni confirmaciones de recepción negativas.
Total de bytes de mensajes pendientes define el tamaño total máximo de los mensajes entregados al cliente para los que Pub/Sub no recibió confirmaciones ni confirmaciones negativas.
Si se supera el límite de una de estas opciones, el cliente suscriptor no extrae más mensajes. Este comportamiento continúa hasta que se confirman o se confirman de forma negativa los mensajes que ya se extrajeron. De esta manera, puedes equilibrar la capacidad de procesamiento con el costo asociado a la ejecución de más suscriptores.
Cómo controlar las entregas duplicadas
De forma predeterminada, Pub/Sub proporciona la entrega de mensajes al menos una vez a los suscriptores. Esto significa que los mensajes se pueden entregar varias veces, incluso si se confirmaron. En las siguientes secciones, se explica cómo abordar situaciones comunes de reintentos de entrega.
Reintento de entrega constante de muchos mensajes
Si experimentas casos en los que muchos mensajes siempre se vuelven a entregar, significa que tus suscriptores están sobrecargados o no confirman la recepción de los mensajes antes de que venza el plazo.
Si usas una suscripción de extracción, es posible que debas establecer valores personalizados para los valores de control de flujo o aumentar los períodos de extensión de la concesión con la administración de concesiones.
Si usas suscripciones de envío, es posible que debas aumentar el parámetro de configuración de la fecha límite de confirmación. También puedes seguir las prácticas recomendadas para mantener una suscripción en buen estado.
Reenvío ocasional de mensajes
Cuando veas que los mensajes se vuelven a entregar antes de que haya pasado la fecha límite de confirmación o después de que se hayan confirmado en unos segundos, Pub/Sub se comporta como se espera. No deberías ver estos picos de reintentos de entrega con frecuencia, pero, cuando ocurren, es probable que se produzcan en varios mensajes de forma simultánea. Tu sistema debe estar diseñado para tolerar estos duplicados ocasionales.
Reintento de entrega repetido de algunos mensajes
Cuando veas que una pequeña cantidad de mensajes se entrega varias veces, primero confirma que los estás confirmando. Si no es así, averigua por qué tu suscriptor no controla los mensajes de forma correcta. Te recomendamos configurar un tema de mensajes no entregados para evitar más reintentos de entrega. Si confirmas el mensaje, es posible que Pub/Sub siga funcionando como se espera. Si bien es muy poco frecuente, es posible que una pequeña cantidad de mensajes se entregue varias veces si hay interrupciones internas de la red o del hardware. El servicio intenta recuperarse por sí mismo en estos casos, pero las soluciones pueden tardar varios minutos en activarse.
Tu sistema debe ser tolerante a los reintentos de entrega. Puedes reducir su probabilidad asegurándote de procesar y confirmar los mensajes lo más rápido posible.
Si tu aplicación no puede tolerar ningún duplicado, puedes habilitar la entrega exactamente una vez. Recuerda que esta función solo está disponible para las suscripciones de extracción y que también genera una mayor latencia de publicación a suscripción. Evalúa si la compensación de una latencia más alta es aceptable para tu caso de uso antes de habilitar esta función.
Prácticas recomendadas para la mensajería ordenada en la suscripción
Si usas el ordenamiento de mensajes, asegúrate de lo siguiente:
Elige entre las suscripciones de StreamingPull o de extracción. En el caso de una suscripción de envío, Pub/Sub solo admite un mensaje pendiente para cada clave de ordenamiento a la vez. Enviar solicitudes de envío push paralelas en una situación de este tipo sería similar a enviar varios lotes de mensajes para la misma clave de ordenamiento a los suscriptores de extracción de forma simultánea. Por lo tanto, no se recomiendan las suscripciones de envío para los temas en los que se publican con frecuencia varios mensajes con la misma clave de ordenamiento o en los que la latencia es muy importante.
Habilita el orden de los mensajes en la suscripción. En el lado del publicador, si envías mensajes con una clave de ordenamiento y en la misma región, puedes configurar los suscriptores para que reciban esos mensajes en orden. En el lado del suscriptor, habilita la propiedad de ordenamiento de mensajes solo para las suscripciones en las que quieras recibir mensajes ordenados. Según el estado de la propiedad, cada suscripción adjunta al tema puede determinar si necesita una entrega ordenada sin afectarse entre sí.
Confirma la recepción de los mensajes en orden. Cuando se usa la entrega ordenada, las confirmaciones de recepción de los mensajes posteriores no se procesan hasta que se procesen las confirmaciones de recepción de los mensajes anteriores por clave de ordenamiento. Por ejemplo, si tienes los mensajes 1, 2 y 3 con la misma clave de ordenamiento y los recibes todos, pero solo confirmas el mensaje 3, el servicio no considerará el mensaje 3 como confirmado hasta que también se confirmen los mensajes 1 y 2. Si nunca se reciben las confirmaciones de recepción de los mensajes 1 y 2, se vuelven a entregar los mensajes 1, 2 y 3.
Resumen de prácticas recomendadas
En la siguiente tabla, se resumen las prácticas recomendadas de este documento.
| Tema | Tarea |
|---|---|
| Elige un tipo de suscripción | Elige el tipo de suscripción adecuado para las necesidades de tu empresa. Si tu suscripción lo admite, usa también la biblioteca cliente de alto nivel. |
| Vuelve a reproducir un mensaje confirmado | Procesa un mensaje antes de confirmarlo. O bien, configura una operación de búsqueda para no perder los mensajes confirmados. |
| Control de flujo | Configura el control de flujo en la configuración de tu suscriptor para asegurarte de que los suscriptores no se sobrecarguen hasta que se active el ajuste de escala automático o pase el tiempo. |
| Controla las entregas duplicadas y conserva los IDs de los mensajes | Conserva o habilita el registro de los messageId recibidos para simplificar la solución de problemas de duplicados, reintentos de entrega y mensajes faltantes. |
| Ordena mensajes | Cuando uses la mensajería ordenada, elige StreamingPull o Pull, habilita el ordenamiento de mensajes en la suscripción y confirma los mensajes en orden. |