En este documento, se proporcionan algunas sugerencias comunes para solucionar problemas relacionados con las suscripciones a StreamingPull de Pub/Sub. Las suscripciones de StreamingPull usan la API de StreamingPull.
Obtén más información sobre las suscripciones a StreamingPull en la Guía del suscriptor de extracción.
StreamingPull tiene una tasa de error del 100%
Las transmisiones de StreamingPull siempre se cierran con un estado que no es correcto. A diferencia de las RPC unarias, este estado para StreamingPull es simplemente una indicación de que la transmisión está rota. Las solicitudes no fallan. Por lo tanto, aunque la API de StreamingPull puede tener una tasa de error sorprendente del 100%, este comportamiento es por diseño.
Errores de condición previa, no disponible o no encontrado
Dado que las transmisiones de StreamingPull siempre se cierran con un error, no es útil examinar las métricas de finalización de transmisión mientras diagnosticas errores. En su lugar, enfócate en la métrica de respuesta de StreamingPull, como subscription/streaming_pull_response_count.
Busca estos errores:
Errores de condición previa fallida que pueden ocurrir en los siguientes casos:
Pub/Sub intenta desencriptar un mensaje con una clave de Cloud KMS inhabilitada.
Las suscripciones se suspenden de manera temporal si hay mensajes en las tareas pendientes de suscripción que se encriptan con una clave de Cloud KMS inhabilitada.
Errores no disponibles que pueden ocurrir cuando Pub/Sub no puede procesar una solicitud. Lo más probable es que esta sea una condición transitoria y la biblioteca cliente vuelva a intentar las solicitudes.
Errores "No encontrado" que pueden ocurrir cuando se borra la suscripción o cuando nunca existió. El último caso ocurre cuando proporcionas una ruta de suscripción no válida.
Gran cantidad de mensajes pequeños pendientes en una suscripción de StreamingPull
La pila gRPC de StreamingPull está optimizada para lograr una gran capacidad de procesamiento y, por lo tanto, almacena los mensajes en el búfer. Si intentas procesar grandes cantidades de mensajes pequeños, es posible que veas mensajes entregados varias veces. Es posible que estos mensajes no se balanceen de manera eficaz entre los clientes.
El búfer entre el servicio de Pub/Sub y el espacio de usuario de la biblioteca cliente es de alrededor de 10 MB. Para comprender el efecto de este búfer en el comportamiento de la biblioteca cliente, considera el siguiente ejemplo:
Hay 10,000 mensajes de 1 KB pendientes en una suscripción.
Cada mensaje tarda un segundo en el procesamiento secuencial de una instancia de cliente de un solo subproceso.
La primera instancia de cliente que establece una conexión de StreamingPull con el servicio para esa suscripción llena su búfer con los 10,000 mensajes.
Tarda 10,000 segundos (casi tres horas) en procesar el búfer.
En ese tiempo, algunos mensajes almacenados en búfer superan los plazos de confirmación de recepción y se vuelven a enviar al mismo cliente, lo que genera duplicados.
Cuando se ejecutan varias instancias de cliente, los mensajes atascados en el búfer de un cliente no están disponibles para ninguna otra instancia de cliente. Esta situación no se produce si usas el control de flujo para StreamingPull. El servicio nunca tiene los 10 MB completos de mensajes a la vez y puede balancear la carga de mensajes de manera efectiva entre varios suscriptores.