En esta guía, se proporciona información y una descripción general de las funciones de confiabilidad de Pub/Sub.
¿Por qué elegir Pub/Sub?
Como paradigma de mensajería, la publicación y suscripción se diseñó para desacoplar a los productores de mensajes de los consumidores de esos mensajes. En lugar de que los productores envíen solicitudes directas a los consumidores con los datos, publican esos datos en un servicio de Pub/Sub, como Pub/Sub. El servicio entrega esos mensajes de forma asíncrona a los consumidores interesados que se suscribieron.
El resultado es que el servicio absorbe todas las complejidades de encontrar consumidores interesados en los datos. El servicio también administra la velocidad a la que los consumidores reciben los datos, según su capacidad. La separación permite que los productores de datos escriban mensajes a gran escala con baja latencia, independientemente del comportamiento de los consumidores.
Pub/Sub ofrece una entrega de mensajes confiable y altamente escalable. Si bien el servicio controla gran parte de esto de forma automática, tienes control sobre diferentes aspectos de tus publicadores y suscriptores que pueden afectar la disponibilidad y el rendimiento. En el resto de esta guía, se proporcionan algunos detalles sobre estos aspectos.
Aislamiento
De forma predeterminada, Pub/Sub es un servicio global: los temas y las suscripciones no están vinculados de forma inherente a regiones específicas, y los mensajes fluyen dentro del servicio de Pub/Sub entre regiones cuando es necesario. Cuando se usa el extremo global, pubsub.googleapis.com, los publicadores y los suscriptores se conectan a la región más cercana a la red en la que se ejecuta Pub/Sub. Cuando se usan los extremos regionales, como us-central1-pubsub.googleapis.com, o los extremos de ubicación, como pubsub.us-central1.rep.googleapis.com, los publicadores y suscriptores se conectan a Pub/Sub en la región especificada. Cuando ejecutes publicadores o suscriptores fuera de Cloud de Confiance, es mejor usar extremos regionales o de ubicación para garantizar que los mensajes fluyan entre las regiones esperadas de manera coherente.
Aislamiento regional
Para minimizar la infraestructura de la que dependen las operaciones de publicación y suscripción fuera de una sola región y garantizar que todos los datos permanezcan aislados en esa región, sigue estos pasos:
Crea un tema por región.
Si bien el espacio de nombres de Pub/Sub es global y no puedes vincular temas y suscripciones a una región específica, los metadatos de todos los recursos se replican en los almacenes de datos locales dentro de la región. Por lo tanto, una vez que creas un recurso, su configuración está disponible incluso en caso de que haya un problema en otra región. Ten en cuenta que las actualizaciones de la configuración del tema o de la suscripción pueden no propagarse de inmediato en caso de interrupción.
Evita usar extremos globales.
En su lugar, usa endpoints regionales cuando estén disponibles y endpoints de ubicación cuando no haya endpoints regionales disponibles. Los extremos regionales ofrecen más aislamiento regional, pero aún no están disponibles en todas las regiones.
Usa una política de almacenamiento de mensajes y establece
enforceInTransitenTrue.Con Aplicar en tránsito, los datos nunca salen de la región y todos los clientes que se conectan al tema en una región específica configuran la política de almacenamiento de mensajes para esa región.
Con los temas configurados de esta manera, puedes tener la certeza de que todas las operaciones de publicación y suscripción escriben y leen datos exclusivamente dentro de la región. En caso de fallas del publicador, del suscriptor o de Pub/Sub en una sola región, se detiene la entrega de mensajes en esa región. La entrega de mensajes en temas y suscripciones de otras regiones no se ve afectada.
Si también necesitas que las operaciones administrativas y el espacio de nombres de tus temas y suscripciones estén aislados de forma regional, considera usar Managed Service para Apache Kafka.
Conmutación por error
Si no necesitas aislamiento regional, te recomendamos que aproveches la capacidad de Pub/Sub para entregar mensajes de manera eficiente en varias regiones y, así, lograr capacidades de conmutación por error multirregional. El resto de esta sección explica cómo crear temas y suscripciones, y cómo ubicar publicadores y suscriptores para admitir diferentes tipos de conmutación por error y redundancia de datos.
Semántica de conmutación por error predeterminada
Considera un caso en el que hay un solo tema y una sola suscripción. Los editores se encuentran en regiones de Estados Unidos y Australia, y los suscriptores en las Cloud de Confiance regiones de Europa y Australia. En el caso en que todos los suscriptores tengan capacidad suficiente para recibir mensajes, el flujo de mensajes se ve de la siguiente manera:
Las P representan a los publicadores y las S, a los suscriptores. El hexágono azul representa el servicio de Pub/Sub. Los cilindros representan los lugares donde se almacenan los mensajes (los mensajes siempre se conservan en varias zonas de la región en la que se publican). Pub/Sub prefiere enviar mensajes dentro de la misma región en la que se publicaron cuando hay suscriptores disponibles. De lo contrario, envía los mensajes a la región más cercana a la red con suscriptores que tienen capacidad. Por lo tanto, como se muestra en la imagen anterior, los mensajes publicados en Estados Unidos se entregan a los suscriptores de Europa, y los mensajes publicados en Australia permanecen en Australia.
En las siguientes secciones, se analiza lo que sucede en diferentes situaciones de falla.
Los suscriptores de Europa no están disponibles
Supongamos que se rechazaron los suscriptores de Europa o que fallan con frecuencia y no pueden mantener una conexión con Pub/Sub. Si esto ocurriera, el servicio comenzaría a entregar mensajes a los suscriptores de Australia:
Los suscriptores de Europa y Australia no están disponibles
En el caso de que todos los suscriptores no estén disponibles, Pub/Sub almacenará los mensajes hasta el período de retención de mensajes configurado.
Una vez que los suscriptores se vuelven a conectar, se entregan los mensajes, a menos que la interrupción dure más que el período de retención de mensajes configurado. De forma predeterminada, la retención de mensajes de suscripción se establece en 7 días. También puedes configurar la retención de mensajes en un tema por hasta 31 días. No elijas una duración de retención de mensajes más corta que la interrupción máxima que esperas o que estás dispuesto a tolerar.
Pub/Sub no está disponible en Europa
Aunque es poco frecuente, también es posible que desees abordar los casos en los que Pub/Sub no está disponible. La falta de disponibilidad de Pub/Sub se manifiesta como períodos prolongados de errores inesperados en las solicitudes de publicación o suscripción, o la incapacidad de entregar mensajes publicados a los suscriptores. Por ejemplo, si Pub/Sub no funcionara en la región de Europa, la situación sería muy similar a cuando no funcionan los suscriptores:
Ten en cuenta que, en este caso, los suscriptores de Europa no conmutan por error a otra región, incluso si usan el extremo global. Pub/Sub no realiza una conmutación por error automática de forma intencional. Imagina que son los suscriptores los que causan un problema inesperado en Pub/Sub que genera indisponibilidad. Este tipo de problema se considera una interrupción grave. Sin embargo, el alcance del impacto de la interrupción se puede limitar a la región a la que se conectaron los suscriptores. Si el servicio les permitiera conmutar por error a otra región, los suscriptores también podrían causar indisponibilidad allí, lo que provocaría una falla en cascada en todo el servicio.
Los publicadores de Australia no están disponibles
Si los publicadores de una región dejan de estar disponibles, los mensajes que ya se publicaron se seguirán entregando a los suscriptores más cercanos:
Con el tiempo, los suscriptores consumen y confirman todos los mensajes. Cuando se envían mensajes, Pub/Sub intenta minimizar la distancia de red. Por lo tanto, los suscriptores de la región de Australia pueden dejar de recibir mensajes si los suscriptores de Europa tienen capacidad suficiente para controlar todos los mensajes publicados en Estados Unidos.
Pub/Sub no está disponible en Estados Unidos
Pub/Sub escribe mensajes de forma síncrona en varias zonas dentro de una región. Por lo tanto, una interrupción zonal no es suficiente para evitar la entrega de mensajes; toda la región debe estar no disponible. Si Pub/Sub deja de estar disponible en una región en la que los publicadores envían mensajes, es posible que los mensajes de esa región no se entreguen hasta que se restablezca por completo el servicio:
En última instancia, el mensaje se entrega (siempre y cuando no haya pasado el período de retención de mensajes), pero se retrasa por la duración de la interrupción. Ten en cuenta que, al igual que los suscriptores, los publicadores de Estados Unidos no conmutan por error a otra región cuando falla el servicio. Este comportamiento ayuda a evitar la probabilidad de fallas en cascada en las regiones debido a un publicador o suscriptor defectuoso.
Conmutación por error y redundancia controladas por el cliente
Es posible que la semántica de conmutación por error predeterminada de Pub/Sub no garantice por completo que los mensajes siempre puedan fluir de los publicadores a los suscriptores si hay una interrupción en cualquier punto intermedio. Las interrupciones pueden ocurrir en varios lugares diferentes, incluidos tus clientes, el servicio en el que se ejecutan tus publicadores o suscriptores, la red o, incluso, rara vez, en Pub/Sub. Si necesitas que tus servicios sean resistentes a estas interrupciones, debes implementar tus propias redundancias. Por lo general, estas redundancias incluyen el uso de varias instancias de clientes de publicadores y suscriptores, en las que cada una usa un extremo de ubicación diferente.
Es posible que desees tener capacidad de recuperación ante dos tipos diferentes de alcance del impacto: zonal o regional. Estas son las opciones de configuración para cada uno.
Resiliencia zonal
Pub/Sub tiene replicación entre zonas integrada. No tienes que seguir ningún paso especial para solucionar las interrupciones de una sola zona que afectan el servicio en sí. Sin embargo, para tener resiliencia ante las interrupciones de tus clientes o de la red, es mejor ejecutar publicadores y suscriptores con capacidad suficiente en varias zonas dentro de la región. Si una sola zona está inactiva, los clientes de la otra zona pueden captar el tráfico y procesar los mensajes. Se recomienda no publicar los cambios en estos clientes de forma simultánea para que, si se introduce un error, las otras zonas intactas puedan seguir procesando mensajes.
Resiliencia regional
Para que tu sistema sea resistente a las fallas regionales, configura redundancias adicionales en tus publicadores y suscriptores. Puedes ejecutar publicadores y suscriptores en varias regiones para hacer frente a la posibilidad de interrupciones en esos clientes o en las redes.
Si deseas tener resiliencia ante posibles fallas de Pub/Sub en una región, debes tener un mecanismo de conmutación por error listo para hacer frente a una interrupción de este tipo. Los enfoques posibles representan una compensación entre la latencia de entrega de mensajes de extremo a extremo y el costo.
Para minimizar la latencia en caso de que el costo no sea un problema, la mejor estrategia es publicar y suscribirse de forma simultánea en diferentes regiones. Primero, elige la cantidad de regiones en las que deseas tener redundancia. A continuación, aunque no es estrictamente necesario, puedes configurar un tema y una suscripción para cada una de esas regiones.
Cada publicador crea tantos clientes de publicador como regiones haya (uno para cada región) y usa un endpoint de ubicación diferente para garantizar que los mensajes se dirijan a regiones distintas. Si se usan temas separados, cada cliente publicador debe publicar en el tema correspondiente por región. Para cada mensaje, el publicador llama a publish en cada cliente. Con las publicaciones redundantes, no es necesario volver a intentarlo si falla alguna de ellas.
Del mismo modo, cada suscriptor crea esa cantidad de clientes suscriptores (uno para cada región) y usa un extremo de ubicación para conectarse a una región diferente. Si se usan suscripciones diferentes para cada región, cada cliente suscriptor debe usar la suscripción correspondiente. Ten en cuenta que las regiones que se usan para los publicadores y los suscriptores no necesariamente tienen que ser las mismas. Los suscriptores reciben mensajes en las tres suscripciones y los procesan.
Esta configuración tiene varios requisitos y funciones clave:
- Las interrupciones en una sola región no afectan el procesamiento de los mensajes ya publicados ni los que se publican durante la interrupción. Dado que los mensajes se publicaron en varias regiones, siguen estando disponibles en otras regiones en caso de que una región haya fallado. Durante la interrupción, las llamadas de publicación fallan en la región afectada, pero se realizan correctamente en las demás.
- La latencia del procesamiento de mensajes no se ve afectada siempre que esté disponible cualquiera de las regiones por las que fluyen los mensajes.
- El procesamiento de mensajes debe ser idempotente. Dado que cada mensaje se entregará varias veces, el procesamiento de mensajes debe ser resistente a los duplicados. En caso de una interrupción regional, es posible que algunos de esos duplicados lleguen mucho más tarde que la primera vez que se entregó el mensaje. Es probable que esos duplicados provengan de una región diferente que no estaba experimentando una interrupción.
Ejecutar con este tipo de redundancia proporciona la mayor capacidad de recuperación ante cualquier tipo de interrupción. Esta configuración es la preferida para los servicios internos de Google que dependen de Pub/Sub y requieren la mayor disponibilidad. Sin embargo, esta configuración tiene la desventaja de multiplicar el costo de entrega de mensajes por la cantidad de regiones utilizadas. También se suma el costo adicional del uso de la red interregional para los mensajes que deben trasladarse entre regiones.
Otro enfoque para la redundancia es conmutar por error solo cuando fallan las solicitudes o los mensajes no fluyen de los publicadores a los suscriptores según lo esperado. En este caso, tienes una región principal a la que diriges a tus publicadores y suscriptores a través de extremos basados en la ubicación. Al igual que antes, no es necesario que sean la misma región. También tendrás una región de respaldo para los publicadores y suscriptores que se usará cuando la región principal no esté disponible.
Los publicadores solo publican en la región principal (a través del extremo de ubicación) cuando sus solicitudes se envían correctamente. Cuando se determina que la región está inactiva, los publicadores comienzan a publicar en la región de respaldo. Determinar que la región está inactiva y realizar la conmutación por error se puede hacer de dos maneras. Se puede hacer con un proceso manual, y la configuración se actualiza de forma dinámica en los editores. Los publicadores también pueden actualizar la configuración por su cuenta si el porcentaje de errores en las solicitudes de publicación es lo suficientemente alto.
Los suscriptores siempre deben conectarse a la región principal a través del extremo de ubicación. Puedes decidir que el suscriptor use la región de respaldo con uno o más de los siguientes activadores:
- Siempre se debe suscribir a la región de resguardo. En este caso, el suscriptor mantiene una conexión con la región principal y la región de resguardo en todo momento. Se pueden usar las mismas regiones para la principal y la secundaria, tanto para los publicadores como para los suscriptores. Si este es el caso, el suscriptor solo debe recibir mensajes a través de la región de copia de seguridad si el publicador conmutó por error.
- Detectar y cambiar manualmente los suscriptores a la región de respaldo a través de una configuración Si detectas una interrupción, puedes conmutar por error a la región de respaldo y, luego, volver a la región principal cuando la interrupción haya disminuido.
- Conmutación por error en caso de errores del suscriptor. Si las solicitudes de los suscriptores devuelven errores, puedes usar esto como indicación de que debes conmutar por error a la región de respaldo. Ten en cuenta que las bibliotecas cliente de Pub/Sub reintentan las solicitudes de extracción de transmisión de forma interna en caso de errores transitorios, por lo que es posible que no puedas detectar que hay largos períodos de errores inesperados. Además, se espera que la tasa de errores de extracción de transmisión sea del 100%, incluso durante el funcionamiento normal.
- Realiza una conmutación por error si el suscriptor pasa un tiempo inesperadamente largo sin recibir mensajes. Si se publican mensajes de forma constante, los suscriptores siempre podrán recibirlos. Si pasan por un período prolongado sin recibir mensajes, es posible que haya un problema del lado de la suscripción en Pub/Sub en la región principal. Esto se soluciona conmutando por error a la región de respaldo.
De las cuatro opciones, la primera es la ideal. Una conexión de suscriptor no cuesta dinero si no fluyen mensajes en ella. El único costo se encuentra en la huella de la instancia adicional de la biblioteca cliente del suscriptor, que puede ser insignificante. También debes tener en cuenta la cuota de cantidad de conexiones de StreamingPull abiertas por región.
La ventaja de este segundo modelo es que no hay un multiplicador en el costo de Pub/Sub, ya que los mensajes solo se publican una vez. Sin embargo, la desventaja es que, para ciertos tipos de interrupciones, es posible que los mensajes publicados antes de que comenzara la interrupción no estén disponibles hasta que se resuelva. Es posible que los mensajes almacenados en la región que no está disponible no se puedan entregar a los suscriptores, independientemente de dónde estén conectados. Es posible que estén disponibles los mensajes publicados durante la interrupción en la región de respaldo. Además, es posible que haya un período de no disponibilidad con mayores tasas de error para los publicadores o los suscriptores. Esto depende del método que se use para detectar una interrupción y del tiempo que se tarde en conmutar por error a la región de respaldo.
Sin importar la opción que elijas, ten en cuenta cómo puede interactuar con las funciones de Pub/Sub. Tanto la entrega ordenada como la entrega exactamente una vez ofrecen sus garantías dentro de una región. Por ejemplo, si usas la técnica de redundancia de conmutación por error, se garantiza que la entrega de mensajes se realizará en orden solo para los mensajes publicados en la misma región. El suscriptor podría recibir mensajes publicados en la región de respaldo antes que los mensajes publicados en la región principal, incluso si los mensajes se publicaron primero en la región principal.
Ajuste de publicadores
Independientemente de la opción de conmutación por error que elijas, hay algunos pasos de ajuste adicionales que debes seguir en los publicadores. Ajustar el comportamiento del publicador garantiza un rendimiento óptimo con una carga alta. El procesamiento por lotes de mensajes es una forma de intercambiar latencia por un costo reducido, pero no es una preocupación de confiabilidad, por lo que no se aborda aquí. En cambio, enfócate en algunos de los otros parámetros que son útiles para ajustar la confiabilidad, incluidos los parámetros de configuración de reintentos y los parámetros de configuración de control de flujo.
Las publicaciones pueden fallar por diferentes motivos, incluidos los transitorios, como la falta de disponibilidad de la red, o los que requieren la intervención del usuario, como los cambios de permisos. La biblioteca cliente de Pub/Sub vuelve a intentar realizar las operaciones que generaron errores transitorios con los parámetros especificados en la configuración de reintentos. Estos parámetros de configuración controlan el comportamiento de la retirada exponencial en los reintentos de las RPC de publicación que fallan por motivos transitorios. Si bien la configuración predeterminada suele funcionar bien en la mayoría de los casos, hay situaciones en las que tal vez desees ajustar estos valores.
Las dos propiedades que es más probable que desees ajustar son el tiempo de espera de RPC inicial y el tiempo de espera total. El tiempo de espera de RPC inicial es el tiempo que se le otorga a la primera RPC de publicación para que se complete. Si alguna RPC falla o se agota su tiempo de espera, se intenta otra con un tiempo de espera más largo hasta que se supera la cantidad total de solicitudes o el tiempo de espera total.
El tiempo de espera inicial se puede ajustar si tu publicador tiene restricciones de red o está lejos del centro de datos Cloud de Confiance by S3NS más cercano que ejecuta Pub/Sub. Las restricciones de red podrían ser limitaciones en la capacidad de procesamiento de la máquina en la que se ejecuta el publicador o podrían ser el resultado de otros servicios que se ejecutan en la misma máquina y que requieren mucha red. Si el tiempo de espera es demasiado corto, es posible que las RPC iniciales fallen repetidamente, lo que requerirá más intentos (con tiempos de espera más largos) para publicar correctamente. La necesidad repetida de reintentos aumenta la latencia de publicación. En esta situación, aumentar el tiempo de espera inicial podría generar publicaciones más rápidas.
Si la conexión de red no es confiable, aumentar el tiempo de espera total y el tiempo de espera inicial podría ayudar. Un tiempo de espera total mayor le da más tiempo a la RPC de publicación para completarse correctamente. Cuando las RPC de publicación fallan de forma constante con errores de tiempo de espera excedido, considera ajustar estos valores.
Los errores continuos por incumplimiento de la fecha límite en la publicación también pueden indicar la necesidad de ajustar el control de flujo del publicador. Estos parámetros de configuración te permiten garantizar que tus publicadores sean resistentes a los aumentos repentinos de tráfico entrante que generan más mensajes para enviar a Pub/Sub. Un gran aumento en las solicitudes salientes podría sobrecargar la CPU, la memoria o la capacidad de red del publicador. Cuando la publicación está sobrecargada, no puede procesar solicitudes ni respuestas de publicación antes de que se agote el tiempo de espera. Esto genera aún más solicitudes de publicación y, en última instancia, se alcanza el tiempo de espera total. El control de flujo del publicador limita la cantidad de mensajes o bytes que pueden estar pendientes sin una respuesta de la solicitud de publicación. Limitar la cantidad de solicitudes de esta manera mantiene el uso de recursos en un nivel que se puede administrar, incluso durante los picos. Según cómo opere tu publicador, puedes permitir que las RPCs de publicación posteriores esperen capacidad permitiendo que la publicación bloquee más solicitudes. Como alternativa, puedes rechazar las llamadas a tu servicio haciendo que el control de flujo devuelva un error cuando se alcance la capacidad. Configuras cómo responde la biblioteca cliente del publicador con el comportamiento de límite excedido.
Suscriptores de ajustes
También es posible que se requiera un ajuste del suscriptor para garantizar que funcione de forma confiable. Al igual que los publicadores, puedes ajustar la configuración del control de flujo de los suscriptores para asegurarte de que no se saturen. La biblioteca cliente del suscriptor usa la extracción de transmisión, en la que el cliente abre una transmisión persistente al servidor y el servidor envía mensajes a medida que están disponibles. En el caso de un gran aumento en los mensajes publicados, es posible que el suscriptor reciba más mensajes de los que puede procesar. Con el control de flujo, se limita la cantidad de mensajes pendientes sin confirmar que se envían al cliente en un momento determinado. Esto reduce la cantidad de mensajes que se controlan de forma simultánea y distribuye su procesamiento durante un período más prolongado. Distribuir la carga permite que los suscriptores se mantengan dentro de las limitaciones de recursos que afectan el procesamiento de mensajes, lo que puede generar un efecto en cascada que se convierta en la incapacidad de procesar mensajes.
El control de flujo por sí solo es suficiente si solo esperas picos en la cantidad de datos que se procesarán y que, en última instancia, disminuirán. Si el tráfico aumenta con el tiempo debido a un mayor uso, el control de flujo protege a los suscriptores. Sin embargo, esto puede generar una acumulación de mensajes que no se puedan entregar antes de que pase el período de retención. En esos casos, también puedes configurar el ajuste de escala automático para aumentar la cantidad de suscriptores en respuesta a una creciente cantidad de mensajes no confirmados. La forma en que configures esto dependerá de la plataforma de procesamiento que uses para tus suscriptores. Por ejemplo, el escalador automático de Compute Engine te permite escalar en función de métricas como la cantidad de mensajes no entregados. Si usas el ajuste de escala automático y el control de flujo, puedes asegurarte de que tus suscriptores sean resistentes a otros aumentos repentinos a corto plazo en la capacidad de procesamiento de mensajes y al crecimiento a largo plazo que requiere más potencia de procesamiento. Asegúrate de seguir las prácticas recomendadas para usar las métricas de Pub/Sub como un indicador de escalamiento.
Usar la versión regional de las métricas de backlog en lugar de las versiones globales
Cuando supervisas la acumulación de suscripciones, configuras políticas de alertas o ajustas automáticamente la escala de los suscriptores, Pub/Sub ofrece dos versiones de cada métrica de acumulación. Asegúrate de usar las versiones con el sufijo by_region:
No uses las versiones globales de estas métricas (subscription/num_undelivered_messages y subscription/oldest_unacked_message_age) si quieres que tu supervisión, tus alertas y tu ajuste de escala automático sean resistentes a las interrupciones de una sola región. Las versiones globales de estas métricas requieren calcular el backlog en todas las regiones que se sabe que tienen mensajes, lo que significa que la falta de disponibilidad en una sola región genera una brecha de datos. En cambio, las versiones by_region de las métricas calculan y registran el backlog por región. Si no se puede calcular el backlog para una sola región, la métrica seguirá registrando valores para las demás regiones.
Usa la función de instantáneas y búsqueda para implementaciones seguras
La pérdida de mensajes suele ser un evento catastrófico. Pub/Sub ofrece la entrega al menos una vez para todos los mensajes publicados. Sin embargo, el procesamiento correcto de estos mensajes depende del comportamiento del suscriptor. Si los mensajes se confirman correctamente, Pub/Sub no los vuelve a entregar. Por lo tanto, un error introducido en el código nuevo del suscriptor que implementes y que confirme la recepción de mensajes sin haberlos procesado correctamente podría provocar la pérdida de mensajes inducida por el suscriptor. Pub/Sub ofrece la función de instantánea y búsqueda, que puede ayudarte a garantizar que proceses cada mensaje correctamente, incluso en caso de errores del suscriptor.
El patrón para cada implementación de suscriptor debe ser el siguiente:
El tiempo de espera antes de determinar si el nuevo suscriptor funciona puede variar según tu caso de uso. La única forma de salir del flujo de pasos es cuando se considera que un suscriptor funciona, momento en el que se puede borrar la instantánea.
El uso de la función de instantáneas y búsqueda no reemplaza las prácticas recomendadas en torno a la primera ejecución del software en un entorno que no es de producción y la implementación gradual en la producción. Proporcionan un nivel adicional de protección para garantizar el procesamiento confiable de los datos. La desventaja es que buscar la instantánea puede generar la entrega duplicada de mensajes que tu suscriptor procesó correctamente. Sin embargo, dado que Pub/Sub tiene una semántica de entrega al menos una vez de forma predeterminada, tus suscriptores ya son resistentes a la reentrega de mensajes.