En esta guía, se proporciona información y un panorama general de las funciones de confiabilidad de Pub/Sub.
¿Por qué elegir Pub/Sub?
Como paradigma de mensajería, el modelo de publicación-suscripción está diseñado para separar 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.
Como resultado, 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 altamente escalable y confiable. 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 suscriptores se conectan a la
región más cercana de la red en la que se ejecuta Pub/Sub. Cuando usas los
extremos regionales,
como pubsub.us-central1.rep.googleapis.com, o
los extremos de ubicación,
como us-central1-pubsub.googleapis.com, los publicadores y suscriptores
se conectan a Pub/Sub en la región especificada. Cuando ejecutes publicadores o suscriptores fuera de Google Cloud, 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 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 las configuraciones de temas o suscripciones pueden no propagarse de inmediato en caso de una interrupción.
Evita usar extremos globales.
En su lugar, usa extremos regionales cuando estén disponibles y extremos de ubicación cuando no estén disponibles los extremos regionales. 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 establecen la política de almacenamiento de mensajes en esa región.
Con los temas configurados de esta manera, puedes asegurarte de que todas las operaciones de publicación y suscripción escriban y lean 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 para 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, puedes aprovechar la capacidad de Pub/Sub para entregar mensajes de manera eficiente en varias regiones y, así, lograr capacidades de conmutación por error multirregional. En el resto de esta sección, se explica cómo crear temas y suscripciones, y colocar 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 publicadores se encuentran en regiones de Estados Unidos y Australia, y los suscriptores se encuentran en las regiones de Europa y Australia de Google Cloud . En el caso de que todos los suscriptores tengan suficiente capacidad para recibir mensajes, el flujo de mensajes se verá 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 los suscriptores están disponibles. De lo contrario, envía los mensajes a la región más cercana a la red con suscriptores que tengan 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 los suscriptores de Europa se rechazaron o fallaron con frecuencia y no pudieron mantener una conexión con Pub/Sub. Si esto ocurriera, el servicio comenzaría a entregar mensajes a los suscriptores de Australia:
No hay suscriptores disponibles en Europa ni Australia
En caso de que todos los suscriptores no estén disponibles, Pub/Sub almacena los mensajes hasta el período de retención de mensajes configurado.
Una vez que los suscriptores se vuelven a conectar, los mensajes se entregan, 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 estás dispuesto a tolerar.
Pub/Sub no está disponible en Europa
Aunque es poco frecuente, es posible que también quieras 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 imposibilidad de entregar los mensajes publicados a los suscriptores. Por ejemplo, si Pub/Sub estuviera inactivo en la región de Europa, la situación sería muy similar a cuando los suscriptores están inactivos:
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 conmuta por error de forma automática de manera intencional. Imagina que son los propios suscriptores los que causan un problema inesperado en Pub/Sub que genera falta de disponibilidad. Este problema se trata como una interrupción importante. 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 envía 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 suficiente capacidad 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 no estar 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 el servicio por completo:
En última instancia, el mensaje se entrega (suponiendo que no haya transcurrido el período de retención de mensajes), con un retraso equivalente a la duración de la interrupción. Ten en cuenta que, al igual que los suscriptores, los publicadores de Estados Unidos tampoco conmutan por error a otra región cuando falla el servicio. Este comportamiento ayuda a evitar la probabilidad de fallas en cascada en todas 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, en el servicio en el que se ejecutan tus publicadores o suscriptores, en la red o, incluso, en raras ocasiones, en Pub/Sub. Si necesitas que tus servicios sean resilientes a esas interrupciones, debes implementar tus propias redundancias. Por lo general, estas redundancias incluyen el uso de varias instancias de clientes publicadores y suscriptores, en las que cada uno usa un extremo de ubicación diferente.
Es posible que quieras resiliencia para dos alcances de impacto diferentes: zonal o regional. Estas son las opciones de configuración para cada una.
Resiliencia zonal
Pub/Sub tiene replicación entre zonas integrada. No tienes que realizar ningún paso especial para abordar las interrupciones de una sola zona que afecten al servicio en sí. Sin embargo, para tener resiliencia ante interrupciones en tus clientes o tu 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 recibir el tráfico y procesar los mensajes. Se recomienda no publicar cambios en estos clientes de forma simultánea para que, si se introduce un error, las otras zonas que no se modificaron puedan seguir procesando mensajes.
Resiliencia regional
Para resistir ante fallas regionales, configura redundancias adicionales en tus publicadores y suscriptores. Puedes ejecutar publicadores y suscriptores en varias regiones para lidiar con la posibilidad de interrupciones en esos clientes o en las redes.
Si quieres tener resiliencia ante posibles fallas de Pub/Sub en una región, debes tener un mecanismo de conmutación por error listo para lidiar con esa interrupción. Los enfoques posibles son un equilibrio entre la latencia de entrega de mensajes de extremo a extremo y tu costo.
Para minimizar la latencia en caso de que el costo no sea un problema, la mejor estrategia es publicar y suscribirse siempre de forma simultánea en diferentes regiones. Primero, elige la cantidad de regiones en las que quieres 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 publicadores como regiones haya (uno para cada región) y usa un extremo de ubicación diferente para garantizar que los mensajes se dirijan a regiones distintas. Si se usan temas independientes, 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 intentar las publicaciones si alguna falla.
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 usas 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 tienen que ser necesariamente las mismas. Los suscriptores reciben mensajes en las tres suscripciones y los procesan.
Esta configuración tiene varias funciones y requisitos clave:
- Cualquier interrupción en una sola región no afecta el procesamiento de los mensajes ya publicados ni los publicados durante la interrupción. Como los mensajes se publicaron en varias regiones, siguen disponibles en otras regiones en caso de que una región no esté disponible. 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 de procesamiento de mensajes no se ve afectada, siempre y cuando esté disponible alguna 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 resiliente a los duplicados. En caso de una interrupción regional, algunos de esos duplicados pueden llegar 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 haya tenido una interrupción.
La ejecución con este tipo de redundancia proporciona la mayor resiliencia ante cualquier tipo de interrupción. Para los servicios internos de Google que dependen de Pub/Sub y requieren la mayor disponibilidad, se prefiere esta configuración. Sin embargo, esta configuración tiene la desventaja de multiplicar el costo de la entrega de mensajes por la cantidad de regiones utilizadas. También se aplica el costo adicional del uso de la red interregional para los mensajes que se deben mover entre regiones.
Otro enfoque de la redundancia es conmutar por error solo cuando las solicitudes fallan o los mensajes no fluyen de los publicadores a los suscriptores como se espera. En esta situación, tienes una región principal a la que diriges a tus publicadores y suscriptores a través de extremos de ubicación. Como antes, no es necesario que sean la misma región. También tienes una región de resguardo para publicadores y suscriptores que se usa cuando la región principal no está disponible.
Los publicadores publican solo 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 resguardo. Determinar que la región está inactiva y realizar la conmutación por error se puede hacer de dos maneras. Se puede hacer mediante un proceso manual, y la configuración se actualiza de forma dinámica en los publicadores. Los publicadores también pueden actualizar la configuración por su cuenta si la tasa de errores en las solicitudes de publicación es lo suficientemente alta.
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 resguardo con uno o más de los siguientes activadores:
- Suscribirse siempre 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 de resguardo, 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 falló.
- Detecta y cambia de forma manual los suscriptores a la región de resguardo a través de una configuración. Si detectas una interrupción, puedes conmutar por error a la región de resguardo 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 un indicador de que debes conmutar por error a la región de resguardo. 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 períodos prolongados 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.
- Falla si el suscriptor pasa por un tiempo inesperadamente largo sin recibir mensajes. Si se publican mensajes de forma constante, los suscriptores siempre pueden recibirlos. Si pasan un período prolongado sin recibir mensajes, es posible que haya un problema en el lado de la suscripción en Pub/Sub en la región principal. Esto se soluciona conmutando por error a la región de resguardo.
De las cuatro opciones, la primera es la ideal. Una conexión de suscriptor no tiene costo si no hay mensajes que fluyan en ella. El único costo es el de la huella de la instancia adicional de la biblioteca cliente del suscriptor, que puede ser insignificante. También debes tener en cuenta la cantidad de conexiones de extracción de transmisión abiertas por cuota de 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, sin importar dónde estén conectados. Los mensajes publicados durante la interrupción en la región de resguardo pueden estar disponibles. Además, puede haber un período de falta de 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 resguardo.
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, solo se garantiza que la entrega de mensajes se realice en orden para los mensajes publicados en la misma región. El suscriptor podría recibir mensajes publicados en la región de resguardo antes que los mensajes publicados en la región principal, incluso si los mensajes se publicaron primero en la región principal.
Ajusta los publicadores
Independientemente de la opción de conmutación por error que elijas, hay algunos pasos de ajuste adicionales que debes realizar en los publicadores. Ajustar el comportamiento del publicador garantiza un rendimiento óptimo con una carga alta. Agrupar mensajes en lotes es una forma de compensar la latencia para reducir el costo, pero no es un problema de confiabilidad y, por lo tanto, no se trata aquí. En su lugar, 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 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 los errores transitorios con los parámetros especificados en la configuración de reintentos. Esta configuración controla 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 las situaciones, hay casos en los que es posible que quieras 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 da a la primera RPC de publicación para que se complete. Si alguna RPC falla o se agota el tiempo de espera, se intenta otra con un tiempo de espera más largo hasta que se supere la cantidad total de solicitudes o el tiempo de espera total.
El tiempo de espera inicial se puede ajustar si el publicador tiene restricciones de red o está lejos del centro de datos de Google Cloud 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 que consumen mucha red. Si el tiempo de espera se establece en un valor demasiado bajo, las RPC iniciales podrían fallar de forma reiterada, lo que generaría 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 a la RPC de publicación más tiempo para completarse correctamente. Cuando las RPC de publicación fallan de forma constante con errores de plazo excedido, considera ajustar estos valores.
Los errores continuos de plazo excedido en la publicación también pueden indicar la necesidad de ajustar el control de flujo del publicador. Esta configuración te permite garantizar que tus publicadores sean resilientes 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 las solicitudes o 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 manejable, incluso durante los picos. Según cómo funcione tu publicador, puedes permitir que las RPC de publicación posteriores esperen la capacidad permitiendo que la publicación bloquee más solicitudes. Como alternativa, puedes rechazar a los emisores de tu servicio haciendo que el control de flujo devuelva un error cuando se alcance la capacidad. Configura cómo responde la biblioteca cliente del publicador con el comportamiento de límite excedido.
Suscriptores de ajuste
También puede ser necesario ajustar los suscriptores para garantizar que funcionen de forma confiable. Al igual que con 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 este envía mensajes a medida que están disponibles. En caso de un gran aumento en los mensajes publicados, el suscriptor puede recibir más mensajes de los que puede procesar. Con el control de flujo implementado, se limita la cantidad de mensajes no confirmados pendientes para el cliente a la vez. Esto reduce la cantidad de mensajes que se controlan de forma simultánea y distribuye su procesamiento durante un período más largo. 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 cualquier mensaje.
El control de flujo por sí solo es suficiente si solo esperas aumentos repentinos en la cantidad de datos que se procesarán y que, en última instancia, disminuyen. Si el tráfico aumenta de forma general con el tiempo debido a un mayor uso, el control de flujo protege a los suscriptores. Sin embargo, puede generar una acumulación de mensajes que siga aumentando y que impida que se entreguen antes de que transcurra el período de retención de mensajes. En esos casos, también puedes configurar el ajuste de escala automático para que se activen más suscriptores en respuesta a una cantidad creciente de mensajes no confirmados. La forma de configurar esto depende 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. El uso del ajuste de escala automático y el control de flujo te permite garantizar que tus suscriptores sean resilientes 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.
Usa la versión regional de las métricas de tareas pendientes en lugar de las versiones globales
Cuando supervisas la lista de tareas pendientes de tu suscripción, configuras políticas de alertas o
ajustas la escala de los suscriptores automáticamente, Pub/Sub ofrece dos versiones de cada
métrica de la lista de tareas pendientes. 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 la supervisión, las alertas y el ajuste de escala automático sean resilientes a
las interrupciones de una sola región. Las versiones globales de estas métricas requieren calcular
el trabajo pendiente 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, luego, informan la lista de tareas pendientes por región. Si no se puede calcular la lista de tareas pendientes para una sola región, la
métrica aún informa los valores de las otras regiones.
Usa instantáneas y búsquedas para implementaciones seguras
La pérdida de mensajes suele ser un evento catastrófico. Pub/Sub ofrece una entrega de al menos una vez para todos los mensajes publicados. Sin embargo, el procesamiento correcto de estos mensajes depende del comportamiento del suscriptor. Si se confirma la recepción de los mensajes correctamente, Pub/Sub no los vuelve a entregar. Por lo tanto, un error introducido en el código del suscriptor nuevo que implementes y que confirme los 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 de forma correcta, incluso ante errores de los suscriptores.
El patrón para cada implementación de suscriptor debe ser el siguiente:
La cantidad de tiempo que debes esperar antes de determinar si el suscriptor nuevo 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 está funcionando, momento en el que se puede borrar la instantánea.
El uso de instantáneas y búsquedas no pretende reemplazar las prácticas recomendadas para ejecutar primero el software en un entorno que no sea de producción y la implementación gradual en 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 una entrega duplicada de los mensajes que tu suscriptor procesó correctamente. Sin embargo, dado que Pub/Sub tiene una semántica de entrega de al menos una vez de forma predeterminada, tus suscriptores ya son resilientes al reintento de entrega de mensajes.