El equipo de Google Cloud Pub / Sub se complace en anunciar que la entrega ordenada ya está disponible de forma generalizada. Esta nueva característica permite a los suscriptores recibir mensajes en el orden en que fueron publicados sin sacrificar la escala. Este artículo analiza los detalles de cómo funciona la característica y habla sobre algunos errores comunes al intentar procesar mensajes en orden en sistemas distribuidos.
Conceptos básicos de pedidos
Los pedidos en Cloud Pub / Sub constan de dos propiedades. La primera es la clave de pedido establecida en un mensaje al publicar . Esta cadena, que puede tener hasta 1 KB, representa la entidad para la que se deben ordenar los mensajes. Por ejemplo, podría ser un ID de usuario o la clave principal de una fila en una base de datos. La segunda propiedad es la propiedad enable_message_ordering en una suscripción . Cuando esta propiedad es verdadera, los suscriptores reciben mensajes para una clave de pedido en el orden en que fueron recibidos por el servicio.
Estas dos propiedades permiten a los editores y suscriptores decidir de forma independiente si se ordenan los mensajes. Si el editor no especifica claves de pedido con mensajes o el suscriptor no habilita la entrega ordenada, entonces la entrega de mensajes no está en orden y se comporta como Cloud Pub / Sub sin la función de entrega ordenada. No todas las suscripciones a un tema deben tener la misma configuración para enable_message_ordering. Por lo tanto, diferentes casos de uso que reciben los mismos mensajes pueden determinar si necesitan una entrega ordenada sin impactarse entre sí.
El número de claves de pedido está limitado solo por lo que se puede representar con la cadena de 1 KB. El rendimiento de publicación de cada clave de pedido está limitado a 1 MB / s. El rendimiento en todas las claves de pedido de un tema se limita a la cuota disponible en una región de publicación . Este límite se puede aumentar a muchos GB / s.
Todas las bibliotecas cliente de Cloud Pub / Sub tienen una gran compatibilidad con la entrega ordenada. Son la mejor manera de aprovechar esta función, ya que se encargan de muchos de los detalles necesarios para garantizar que los mensajes se procesen en orden. La entrega ordenada funciona con los tres tipos de suscriptores: transmisión pull , pull y push .
Ordenar propiedades
La entrega ordenada tiene tres propiedades principales:
- Orden : cuando una suscripción tiene habilitado el orden de mensajes, los suscriptores reciben mensajes publicados en la misma región con la misma clave de orden en el orden en que fueron recibidos por el servicio.
- Reenvío coherente : si se vuelve a enviar un mensaje, todos los mensajes recibidos después de ese mensaje para la misma clave de pedido también se volverán a enviar, independientemente de que hayan sido reconocidos o no.
- Afinidad : si hay mensajes con una clave de pedido pendiente para un suscriptor de extracción de transmisión, los mensajes adicionales que se entregan se envían a ese mismo suscriptor. Si no hay mensajes pendientes actualmente para una clave de pedido, el servicio entrega mensajes al último suscriptor para recibir mensajes para esa clave con el mejor esfuerzo.
Examinemos qué significan estas propiedades con un ejemplo. Imagine que tenemos dos claves de ordenación, A y B. Para la clave A, publicamos los mensajes 1, 2 y 3, en ese orden. Para la clave B, publicamos los mensajes 4, 5 y 6, en ese orden. Con la propiedad de pedido, garantizamos que 1 se entrega antes de 2 y 2 se entrega antes de 3. También garantizamos que 4 se entrega antes de 5, que se entrega antes de 6. Tenga en cuenta que no hay garantías sobre el orden de los mensajes en diferentes pedidos. llaves. Por ejemplo, el mensaje 1 podría llegar antes o después del mensaje 4.
La segunda propiedad explica qué sucede cuando los mensajes se vuelven a entregar. En general, Cloud Pub / Sub ofrece una entrega al menos una vez. Eso significa que los mensajes se pueden enviar a los suscriptores varias veces, incluso si esos mensajes han sido reconocidos. Con la garantía de reenvío constante, cuando se vuelve a entregar un mensaje, también se volverá a entregar la secuencia completa de mensajes posteriores para la misma clave de pedido que se recibieron después del mensaje reenviado. En el ejemplo anterior, imagina que un suscriptor recibe los mensajes 1, 2 y 3. Si el mensaje 2 se vuelve a enviar (porque la fecha límite de ack expiró o porque el ack de mejor esfuerzo no se mantuvo en Cloud Pub / Sub), entonces el mensaje 3 está garantizado para ser devuelto también.
La última propiedad define dónde se entregan los mensajes para la misma clave de pedido. Se aplica solo a los suscriptores de extracción de transmisión, ya que son los únicos que tienen una conexión de larga data que se puede usar para afinidad. Esta propiedad tiene dos partes. Primero, cuando los mensajes están pendientes para un suscriptor de extracción de transmisión, lo que significa que la fecha límite de confirmación aún no ha pasado y los mensajes no han sido reconocidos, entonces, si hay más mensajes para entregar para la clave de pedido, van al mismo suscriptor.
La segunda parte se refiere a lo que sucede cuando no hay mensajes pendientes. Idealmente, uno quiere que los mismos suscriptores manejen todos los mensajes para una clave de pedido. Cloud Pub / Sub intenta hacer esto, pero hay casos en los que no puede garantizar que continuará entregando mensajes al mismo suscriptor. En otras palabras, la afinidad de una clave podría cambiar con el tiempo. Por lo general, esto se hace con fines de equilibrio de carga. Por ejemplo, si solo hay un suscriptor, se le deben entregar todos los mensajes. Si otro suscriptor comienza, generalmente se querrá que comience a recibir la mitad de la carga. Por lo tanto, la afinidad de algunas de las claves de pedido debe pasar del primer abonado a este nuevo abonado. Cloud Pub / Sub espera hasta que no haya más mensajes pendientes en una clave de pedido antes de cambiar la afinidad de la clave.
Entrega ordenada a escala
Uno de los problemas más difíciles con la entrega ordenada es hacerlo a gran escala. Por lo general, requiere una comprensión previa de las características de escala del tema. Cuando un tema se extiende más allá de esa escala, mantener el orden se vuelve extremadamente difícil. La entrega ordenada de Cloud Pub / Sub está diseñada para escalar con el uso sin que el usuario tenga que pensar en ello.
La forma más común de realizar pedidos a escala es con particiones. Un tema puede estar formado por muchas particiones, cada una de las cuales almacena un subconjunto de los mensajes publicados en el tema. Cuando se publica un mensaje, se elige una partición para ese mensaje, ya sea explícitamente o mediante el hash de la clave o el valor del mensaje en una partición. La "clave" en este caso es lo que Cloud Pub / Sub llama la clave de pedido.
Los suscriptores se conectan a una o más particiones y reciben mensajes de esas particiones. Al igual que en el lado de la publicación, los suscriptores pueden elegir particiones explícitamente o confiar en el servicio de mensajería para asignar suscriptores a las particiones. Los servicios de mensajería basados en particiones garantizan que los mensajes dentro de la misma partición se entreguen en orden.
Una configuración de partición típica se vería así:
Los cuadros verdes representan las particiones que almacenan mensajes. Serían propiedad de los servidores de mensajería (a menudo llamados "intermediarios"), pero hemos omitido esos servidores por simplicidad. Los círculos representan mensajes, el color indica la clave del mensaje y el número indica el orden relativo de los mensajes de ese color.
Uno suele tener muchas menos particiones que claves. En el ejemplo anterior, hay cuatro colores de mensaje, pero solo tres particiones, por lo que la segunda partición contiene mensajes azules y rojos. Hay dos suscriptores, uno que consume desde la primera partición y otro que consume desde la segunda y tercera particiones.
Hay tres problemas principales con los que un usuario puede tener que lidiar cuando usa particiones: limitaciones de escala del suscriptor, fragmentos activos y bloqueo de cabecera de línea. Veamos cada uno en detalle.
Limitaciones de escala de suscriptores
Dentro de un conjunto de suscriptores en los que la entrega de mensajes tiene un equilibrio de carga (a menudo denominado "grupo de consumidores"), solo se puede asignar un suscriptor a una partición en cualquier momento. Por lo tanto, la cantidad máxima de procesamiento paralelo que puede ocurrir es mínimo (# de particiones, # de suscriptores). En el ejemplo anterior, podríamos equilibrar la carga en no más de tres suscriptores:
Si el procesamiento de mensajes de repente se volvió más costoso o, más probablemente, se agregó un nuevo grupo de consumidores para recibir mensajes en una nueva canalización que requiere un procesamiento más prolongado de los mensajes, es posible que no sea posible obtener suficiente paralelismo para procesar todos los mensajes publicados. Una solución sería tener un suscriptor cuyo trabajo sea volver a publicar los mensajes sobre un tema con más fragmentos, que los suscriptores originales podrían consumir en su lugar:
La desventaja es que ahora ambos temas deben mantenerse o se debe realizar una migración cuidadosa para cambiar el editor original para publicar en el nuevo tema. Si se mantienen ambos temas, los mensajes se almacenan dos veces. Es posible que se eliminen los mensajes del primer tema una vez que se publiquen en el segundo tema, pero esto requeriría la migración de los suscriptores que reciben mensajes del tema original al nuevo tema.
Fragmentos calientes
El siguiente problema es un fragmento activo: la sobrecarga de una sola partición. Idealmente, los patrones de tráfico entre las particiones son relativamente similares. Sin embargo, es posible que haya muchos más mensajes o mensajes mucho más grandes en una partición en comparación con los mensajes en otras particiones. Como resultado, una sola partición puede sobrecargarse:
¿Qué se puede hacer para lidiar con este fragmento caliente? Normalmente, la solución es agregar particiones. Sin embargo, mantener el orden durante un reparticionamiento puede resultar muy difícil. Por ejemplo, si agregamos una nueva partición en el caso anterior, podría resultar en que los mensajes relacionados vayan a particiones completamente diferentes:
Con este nuevo conjunto de particiones, los mensajes morados ahora se publican en la primera partición, los mensajes azules en la tercera partición y los mensajes amarillos y rojos en la cuarta partición. Este reparticionamiento causa varios problemas. En primer lugar, la cuarta partición ahora contiene mensajes para claves que anteriormente se dividieron entre los dos suscriptores. Eso significa que la afinidad de las claves con los suscriptores debe cambiar.
Aún más difícil es el hecho de que si los suscriptores quieren que todos los mensajes estén en orden, deben coordinar cuidadosamente desde qué particiones reciben los mensajes y cuándo. Los suscriptores tendrían que estar al tanto del último desplazamiento en cada partición que era para un mensaje antes de agregar más particiones. Luego, necesitan consumir mensajes hasta esas compensaciones. Una vez que hayan procesado los mensajes hasta las compensaciones en todas las particiones, los suscriptores pueden comenzar a consumir mensajes más allá de esa última compensación.
Bloqueo de cabecera de línea
El último problema difícil es el bloqueo del encabezado de línea o la incapacidad de procesar mensajes debido al procesamiento lento de los mensajes que deben consumirse primero. Volvamos al escenario original:
Imagine que los mensajes rojos requieren mucho más tiempo para procesarse que los azules. Al leer mensajes de la segunda partición, el procesamiento del mensaje azul 2 podría retrasarse innecesariamente debido al lento procesamiento del mensaje rojo 1. Dado que la unidad de pedido es una partición, no hay forma de procesar los mensajes azules sin procesar el mensajes rojos. Se podría intentar resolver esto volviendo a particionar con la esperanza de que los mensajes rojo y azul terminen en particiones diferentes. Sin embargo, el procesamiento de los mensajes rojos bloqueará el procesamiento de otros en cualquier partición en la que terminen. El reparticionamiento también da como resultado los mismos problemas discutidos en la sección Hot Shards.
Alternativamente, el editor podría asignar explícitamente los mensajes rojos a su propia partición, pero rompe la separación de los editores y suscriptores si el editor tiene que tomar decisiones basadas en la forma en que los suscriptores procesan los mensajes. También puede ser que el tiempo de procesamiento adicional para los mensajes rojos sea temporal y no justifique cambios a gran escala en el sistema. El usuario tiene que decidir si es mejor el procesamiento retrasado de algunos mensajes o el arduo proceso de cambiar las particiones.
Escalado automático con pedido
La implementación de entrega ordenada de Cloud Pub / Sub está diseñada para que los usuarios no tengan que estar sujetos a tales limitaciones. Puede escalar a miles de millones de claves sin limitaciones de escalado de suscriptores, fragmentos activos o bloqueo de cabecera de línea. Como es de esperar con un pub / subsistema de alto rendimiento, los mensajes se dividen en particiones subyacentes en Cloud Pub / Sub. Sin embargo, hay dos propiedades principales del servicio que le permiten superar los problemas comúnmente asociados con la entrega ordenada:
- Las particiones no están expuestas a los usuarios.
- Los suscriptores reconocen los mensajes individualmente en lugar de avanzar un cursor de partición.
Al aprovechar estas propiedades, los agentes de Cloud Pub / Sub tienen tres comportamientos útiles:
- Asignan suscriptores a grupos de claves de pedidos que son más detallados que una partición.
- Realizan un seguimiento de las tasas de publicación por clave y escalan al número apropiado de particiones según sea necesario, manteniendo una entrega ordenada adecuada en todo el reparticionamiento.
- Almacenan el orden de los mensajes por clave de pedido para que la entrega no sea bloqueada por mensajes para otras claves en la misma partición que aún no se han procesado.
Estos comportamientos permiten que Cloud Pub / Sub evite los tres problemas principales con la entrega ordenada a gran escala.
La entrega ordenada no es gratuita, por supuesto. En comparación con la entrega no ordenada, la entrega ordenada de mensajes puede disminuir ligeramente la disponibilidad de publicación y aumentar la latencia de entrega de mensajes de un extremo a otro. A diferencia del caso no ordenado, donde la entrega puede fallar a cualquier corredor sin ningún retraso, la conmutación por error en el caso ordenado requiere coordinación entre los intermediarios para garantizar que los mensajes se escriban y lean en las particiones correctas.
Uso eficaz de la entrega ordenada
Incluso con la capacidad de Cloud Pub / Sub para entregar mensajes en orden a escala, todavía existen sutilezas cuando se confía en la entrega ordenada. En esta sección se detallan los aspectos a tener en cuenta al crear una canalización ordenada. Algunas de estas cosas también se aplican cuando se utilizan otros sistemas de mensajería con entrega ordenada. Con el fin de proporcionar un buen ejemplo de cómo usar las claves de pedido de manera eficaz, el equipo de Cloud Pub / Sub ha lanzado una versión de código abierto de su sonda de claves de pedido . Este prober es casi idéntico al que ejecuta el equipo de forma continua para verificar el correcto comportamiento de esta nueva función.
Publicando en orden
En la superficie, publicar en orden parece que debería ser muy fácil: simplemente llame a publicar para cada mensaje. Si pudiéramos garantizar que las publicaciones nunca fallan, entonces sería así de simple. Sin embargo, pueden ocurrir fallas transitorias o permanentes con la publicación en cualquier momento, y un editor debe comprender las implicaciones de esas fallas.
Tomemos el ejemplo simple de intentar publicar tres mensajes para las mismas claves de orden A: 1, 2 y 3. El código Java para publicar estos mensajes podría ser el siguiente:
Cadena [] mensajes = {"1", "2", "3"};
para (String msg: messages) {
Mensaje de PubsubMessage = PubsubMessage.newBuilder ()
.setData (ByteString.copyFromUtf8 (msg))
.setOrderingKey ("A")
.construir();
ApiFuture publishFuture = publisher.publish (mensaje);
publishFuture.addListener (() -> {
tratar {
String messageId = publishFuture.get ();
System.out.println ("Publicado correctamente" + messageId);
} captura (Excepción e) {
System.err.println ("No se pudo publicar el mensaje" + msg);
}
}, albacea);
} Si no hubiera fallas, entonces cada llamada de publicación sería exitosa y el ID de mensaje se devolvería en el futuro. Esperamos que el suscriptor reciba los mensajes 1, 2 y 3 en ese orden. Sin embargo, pueden pasar muchas cosas. Si una publicación falla, es probable que deba volver a intentarlo. La biblioteca cliente de Cloud Pub / Sub vuelve a intentar internamente solicitudes sobre errores recuperables. Los errores como la superación de la fecha límite no indican si la publicación se realizó correctamente o no. Es posible que la publicación se haya realizado correctamente, pero el cliente no recibió la respuesta de publicación a tiempo para la fecha límite, en cuyo caso es posible que el cliente haya intentado publicar nuevamente. En tales casos, la secuencia de mensajes podría tener repeticiones, por ejemplo, 1, 1, 2, 3. Cada mensaje publicado tendría su propio ID de mensaje, por lo que desde la perspectiva del suscriptor, parecería que se publicaron cuatro mensajes, con el primero dos con contenido idéntico.
Reintentar las solicitudes de publicación se complica aún más con el procesamiento por lotes . La biblioteca cliente puede agrupar mensajes por lotes cuando los envía al servidor para una publicación más eficiente. Esto es particularmente importante para temas de alto rendimiento. En el caso anterior, podría ser que los mensajes 1 y 2 se agrupen y se envíen al servidor como una sola solicitud. Si el servidor no devuelve una respuesta a tiempo, el cliente volverá a intentar este lote de dos mensajes. Por lo tanto, es posible que el suscriptor pueda ver la secuencia de mensajes 1, 2, 1, 2, 3. Si se quiere evitar estas reediciones por lotes, es mejor establecer la configuración del lote para permitir solo un mensaje en cada lote.
Existe un caso adicional con la publicación que podría causar problemas. Imagine que al ejecutar el código anterior, ocurre la siguiente secuencia de eventos:
- Publicar se llama con el mensaje 1.
- Publicar se llama con el mensaje 2.
- La publicación del mensaje 1 falla temporalmente.
- Publicar se llama con el mensaje 3.
El resultado podría ser que los mensajes 2 y / o 3 se publiquen con éxito y se envíen a los suscriptores sin que se haya enviado 1, lo que resultaría en una entrega fuera de orden. Una solución simple puede ser hacer que las llamadas para publicar sean síncronas:
Cadena [] mensajes = {"1", "2", "3"};
para (String msg: messages) {
Mensaje de PubsubMessage = PubsubMessage.newBuilder ()
.setData (ByteString.copyFromUtf8 ("1"))
.setOrderingKey (mensaje)
.construir();
booleano exitosoPublicado = falso;
while (! SuccessPublish) {
ApiFuture publishFuture = publisher.publish (mensaje);
tratar {
String messageId = publishFuture.get ();
System.out.println ("Publicado correctamente" + messageId);
exitosoPublicado = verdadero;
} captura (Excepción e) {
System.err.println ("No se pudo publicar el mensaje" + msg);
}
}
} Si bien este cambio garantizaría que los mensajes se publiquen en orden, haría mucho más difícil la publicación a gran escala, ya que cada operación de publicación bloquearía un hilo. Las bibliotecas cliente de Cloud Pub / Sub superan este problema de dos maneras. Primero, si una publicación falla y hay otros mensajes para la misma clave de pedido en cola en el búfer de mensajes de la biblioteca, también falla la publicación de todos esos mensajes. En segundo lugar, la biblioteca falla inmediatamente en cualquier llamada de publicación posterior realizada para mensajes con la misma clave de pedido.
¿Cómo se puede volver a publicar en una clave de pedido cuando esto sucede? La biblioteca cliente expone un método, resumePublish (String orderingKey). Un editor debe llamar a resumePublish cuando haya manejado las publicaciones fallidas, determinado lo que quiere hacer y esté listo para publicar mensajes para la clave de pedido nuevamente. El editor puede decidir volver a publicar todos los mensajes fallidos en orden, publicar un subconjunto de los mensajes o publicar un conjunto de mensajes completamente nuevo. Independientemente de cómo quiera el editor manejar este caso extremo, la biblioteca cliente proporciona resumePublish como un medio para hacerlo sin perder las ventajas de escalado de la publicación asincrónica. Eche un vistazo a la lógica de error de publicación del analizador de claves de pedido para ver un ejemplo de cómo utilizar resumePublish.
Todos los temas anteriores se refieren a la publicación de un solo editor. Sin embargo, también está la cuestión de cómo publicar mensajes para la misma clave de pedido de diferentes editores. Cloud Pub / Sub permite esto y garantiza que, para las publicaciones en la misma región, el orden de los mensajes que ven los suscriptores es coherente con el orden en que el corredor recibió las publicaciones. Como ejemplo, digamos que tanto los editores X como Y publican un mensaje para solicitar la clave A. Si Cloud Pub / Sub recibe el mensaje de X antes que el de Y, todos los suscriptores verán los mensajes en ese orden. Sin embargo, los editores no tienen forma de saber en qué orden el servicio recibió los mensajes. Si se debe mantener el orden de los mensajes en diferentes editores, los editores deben utilizar algún otro mecanismo para coordinar sus publicaciones, por ejemplo, algún tipo de servicio de bloqueo para mantener la propiedad de una clave de pedido durante la publicación.
Es importante recordar que las garantías de pedidos son solo para mensajes publicados en la misma región. Por lo tanto, se recomienda encarecidamente que todos los editores utilicen puntos finales de servicio regionales para asegurarse de publicar mensajes en la misma región para la misma clave de pedido. Esto es particularmente importante para los editores alojados fuera de GCP; Si las solicitudes se enrutan a GCP desde otro lugar, siempre es posible que el enrutamiento cambie si se usa el extremo global, lo que podría alterar el orden de los mensajes.
Recibir mensajes en orden
Los suscriptores reciben los mensajes en el orden en que fueron publicados. Lo que significa "recibir mensajes en orden" varía según el tipo de suscriptor. Cloud Pub / Sub admite tres formas de recibir mensajes: transmisión pull , pull y push . Las bibliotecas cliente usan transmisión de extracción (con la excepción de PHP), y hablamos de recibir mensajes a través de transmisión de extracción en términos de uso de la biblioteca cliente. Independientemente del método que se utilice para recibir mensajes, es importante recordar que Cloud Pub / Sub ofrece una entrega al menos una vez. Eso significa que los suscriptores deben ser resistentes a recibir secuencias de mensajes nuevamente, como se explica en la sección Propiedades de pedido. Veamos qué significa recibir mensajes en orden para cada tipo de suscriptor.
Streaming Pull (a través de las bibliotecas cliente)
Cuando se utilizan las bibliotecas cliente, se especifica una devolución de llamada de usuario que debe ejecutarse cada vez que se recibe un mensaje. Las bibliotecas cliente garantizan que para cualquier clave de pedido dada, la devolución de llamada se ejecuta hasta su finalización en los mensajes en el orden correcto. Si los mensajes se reciben dentro de esa devolución de llamada, significa que todos los cálculos de un mensaje se realizan en orden. Sin embargo, si la devolución de llamada del usuario programa otro trabajo asincrónico en los mensajes, el suscriptor debe asegurarse de que el trabajo asincrónico se realice en orden. Una opción es agregar mensajes a una cola de trabajo local que se procesa en orden.
Vale la pena señalar que debido al procesamiento asincrónico en un suscriptor como este, la entrega ordenada en Cloud Pub / Sub no funciona con Cloud Dataflow en este momento. La naturaleza de la ejecución paralelizada de Dataflow significa que no mantiene el orden de los mensajes después de que se reciben. Por lo tanto, la canalización de un usuario no podría depender de que los mensajes se entreguen en orden. Para asegurarse de que no se use Pub / Sub en Dataflow y se espere la entrega ordenada, las canalizaciones de Dataflow que usan una suscripción con claves de pedido habilitadas fallan al iniciarse.
Halar
Para los suscriptores que usan el método de extracción directamente, Cloud Pub / Sub ofrece dos garantías:
- Todos los mensajes para una clave de pedido en la lista de mensajes_recibidos de PullResponse están en el orden correcto en esa lista.
- Hay una lista pendiente de mensajes por clave de pedido a la vez.
El requisito de que solo un lote de mensajes pueda estar pendiente a la vez es necesario para mantener la entrega ordenada. El servicio Cloud Pub / Sub no puede garantizar el éxito o la latencia de la respuesta que envía para la solicitud de extracción de un suscriptor. Si una respuesta falla y una solicitud de extracción posterior se cumple con una respuesta que contiene mensajes posteriores para la misma clave de pedido, es posible que esos mensajes posteriores lleguen al suscriptor antes que los mensajes de la respuesta fallida. Tampoco puede garantizar que la solicitud de extracción posterior provenga del mismo suscriptor.
empujar
Las restricciones al empuje son incluso más estrictas que las del tirón. Para una suscripción push, Cloud Pub / Sub permite que solo haya un mensaje pendiente por clave de pedido a la vez. Dado que cada mensaje se envía a un suscriptor push a través de su propia solicitud, enviar dichas solicitudes en paralelo tendría el mismo problema que entregar múltiples lotes de mensajes para la misma clave de pedido para atraer suscriptores simultáneamente. Por lo tanto, los suscriptores push pueden no ser una buena opción para temas donde los mensajes se publican con frecuencia con la misma clave de orden o la latencia es extremadamente importante, ya que las restricciones podrían impedir que el suscriptor se mantenga al día con los mensajes publicados.
En resumen, la entrega ordenada a escala generalmente requiere que uno tenga mucho cuidado con la capacidad y la configuración de su sistema de mensajería. Cuando se excede esa capacidad o las características de procesamiento de mensajes cambian, agregar capacidad mientras se mantiene el orden es un proceso difícil y que requiere mucho tiempo. Con la introducción de la entrega ordenada en Cloud Pub / Sub, los usuarios pueden confiar en los pedidos de la forma en que están acostumbrados en un sistema que aún escala automáticamente con su uso.
La entrega ordenada de Google Cloud Pub / Sub se publicó originalmente en Google Cloud - Community on Medium, donde las personas continúan la conversación destacando y respondiendo a esta historia.