El orden de los mensajes es una función de Pub/Sub que te permite recibir mensajes en tus clientes suscriptores en el orden en que los publicaron los clientes publicadores.
Por ejemplo, supongamos que un cliente publicador de una región publica los mensajes 1, 2 y 3 en orden. Con el ordenamiento de mensajes, el cliente suscriptor recibe los mensajes publicados en el mismo orden. Para que se entreguen en orden, el cliente publicador debe publicar los mensajes en la misma región. Sin embargo, los suscriptores pueden conectarse a cualquier región y la garantía de ordenamiento se mantiene.
El orden de los mensajes es una función útil para situaciones como la captura de cambios en la base de datos, el seguimiento de sesiones del usuario y las aplicaciones de transmisión en las que es importante conservar la cronología de los eventos.
En esta página, se explica el concepto del orden de los mensajes y cómo configurar tus clientes suscriptores para que reciban mensajes en orden. Para configurar tus clientes publicadores para el ordenamiento de mensajes, consulta Usa claves de ordenamiento para publicar un mensaje.
Descripción general del ordenamiento de mensajes
El ordenamiento en Pub/Sub se determina de la siguiente manera:
Clave de ordenamiento: Es una cadena que se usa en los metadatos de los mensajes de Pub/Sub y representa la entidad para la que se deben ordenar los mensajes. La clave de ordenamiento puede tener una longitud de hasta 1 KB. Para recibir un conjunto de mensajes ordenados en una región, debes publicar todos los mensajes con la misma clave de ordenamiento en la misma región. Algunos ejemplos de claves de ordenamiento son los IDs de cliente y la clave primaria de una fila en una base de datos.
La capacidad de procesamiento de publicación en cada clave de ordenamiento está limitada a 1 MB/s. El rendimiento en todas las claves de ordenamiento de un tema se limita a la cuota disponible en una región de publicación. Este límite se puede aumentar a muchas unidades de GBps.
Una clave de orden no es equivalente a una partición en un sistema de mensajería basado en particiones, ya que se espera que las claves de orden tengan una cardinalidad mucho mayor que las particiones.
Habilita el ordenamiento de mensajes: Este es un parámetro de configuración de la suscripción. Cuando una suscripción tiene habilitado el ordenamiento de mensajes, los clientes suscriptores reciben los mensajes publicados en la misma región con la misma clave de ordenamiento en el orden en que los recibió el servicio. Debes habilitar este parámetro de configuración en la suscripción.
Supongamos que tienes dos suscripciones A y B adjuntas al mismo tema T. La suscripción A está configurada con el ordenamiento de mensajes habilitado, y la suscripción B está configurada sin el ordenamiento de mensajes habilitado. En esta arquitectura, las suscripciones A y B reciben el mismo conjunto de mensajes del tema T. Si publicas mensajes con claves de ordenamiento en la misma región, la suscripción A recibe los mensajes en el orden en que se publicaron. Mientras que la suscripción B recibe los mensajes sin ningún orden esperado.
En general, si tu solución requiere que los clientes publicadores envíen mensajes ordenados y no ordenados, crea temas separados, uno para los mensajes ordenados y otro para los mensajes no ordenados.
Consideraciones para usar la mensajería ordenada
En la siguiente lista, se incluye información importante sobre el comportamiento de los mensajes ordenados en Pub/Sub:
Ordenamiento dentro de la clave: Se espera que los mensajes publicados con la misma clave de ordenamiento se reciban en orden. Supongamos que, para la clave de ordenamiento A, publicas los mensajes 1, 2 y 3. Con el ordenamiento habilitado, se espera que 1 se entregue antes que 2, y que 2 se entregue antes que 3.
Ordenamiento entre claves: No se espera que los mensajes publicados con diferentes claves de ordenamiento se reciban en orden. Supongamos que tienes las claves de ordenamiento A y B. Para la clave de ordenamiento A, los mensajes 1 y 2 se publican en orden. Para la clave de ordenamiento B, los mensajes 3 y 4 se publican en orden. Sin embargo, el mensaje 1 podría llegar antes o después del mensaje 4.
Reenvío de mensajes: Pub/Sub entrega cada mensaje al menos una vez, por lo que el servicio de Pub/Sub podría volver a entregarlos. Los reenvíos de un mensaje activan el reenvío de todos los mensajes posteriores para esa clave, incluso los que tienen confirmación de recepción. Supongamos que un cliente suscriptor recibe los mensajes 1, 2 y 3 para una clave de ordenamiento específica. Si se vuelve a entregar el mensaje 2 (porque venció el plazo de confirmación o la confirmación según el mejor esfuerzo no persistió en Pub/Sub), también se vuelve a entregar el mensaje 3. Si el orden de los mensajes y un tema de mensajes no entregados están habilitados en una suscripción, es posible que este comportamiento no sea así, ya que Pub/Sub reenvía mensajes a temas de mensajes no entregados en base del mejor esfuerzo.
Demoras en la confirmación y temas de mensajes no entregados: Los mensajes no confirmados para una clave de ordenamiento determinada pueden retrasar la entrega de mensajes para otras claves de ordenamiento, en especial durante los reinicios del servidor o los cambios en el tráfico. Para mantener el orden en estos eventos, asegúrate de confirmar la recepción de todos los mensajes a tiempo. Si no es posible confirmar la recepción a tiempo, considera usar un tema de mensajes no entregados para evitar la retención indefinida de mensajes. Ten en cuenta que es posible que no se conserve el orden cuando los mensajes se escriban en un tema de mensajes no entregados.
Afinidad de mensajes (clientes de streamingPull): Por lo general, los mensajes con la misma clave se entregan al mismo cliente suscriptor de streamingPull. Se espera afinidad cuando hay mensajes pendientes para una clave de ordenamiento para un cliente suscriptor específico. Si no hay mensajes pendientes, la afinidad podría cambiar para el balanceo de cargas o las desconexiones del cliente.
Para garantizar un procesamiento sin problemas, incluso con posibles cambios de afinidad, es fundamental diseñar tu aplicación de streamingPull de manera que pueda controlar mensajes en cualquier cliente para una clave de ordenamiento determinada.
Integración con Dataflow: No habilites el orden de mensajes para las suscripciones cuando configures Dataflow con Pub/Sub. Dataflow tiene su propio mecanismo para ordenar los mensajes de forma total, lo que garantiza el orden cronológico en todos los mensajes como parte de las operaciones de ventanas. Este método de ordenamiento difiere del enfoque basado en claves de ordenamiento de Pub/Sub. El uso de claves de ordenamiento con Dataflow puede reducir el rendimiento de la canalización.
Ajuste de escala automático: La entrega ordenada de Pub/Sub se ajusta a miles de millones de claves de orden. Una mayor cantidad de claves de ordenamiento permite una entrega más paralela a los suscriptores, ya que el ordenamiento se aplica a todos los mensajes con la misma clave de ordenamiento.
Compensaciones de rendimiento: La entrega ordenada tiene algunas compensaciones. En comparación con la entrega sin orden, la entrega con orden disminuye la disponibilidad de publicación y aumenta la latencia de entrega de mensajes de extremo a extremo. En el caso de la entrega ordenada, la conmutación por error requiere coordinación para garantizar que los mensajes se escriban y lean en el orden correcto.
Tecla de acceso rápido: Cuando se usa el ordenamiento de mensajes, todos los mensajes con la misma clave de ordenamiento se envían a tu cliente suscriptor en el orden en que los recibe el servicio. La devolución de llamada del usuario no se ejecuta hasta que se completa la devolución de llamada del mensaje anterior. La capacidad de procesamiento máxima para los mensajes que comparten la misma clave de ordenamiento cuando se entregan a los suscriptores no está limitada por Pub/Sub , sino por la velocidad de procesamiento de tu cliente suscriptor. Se produce una clave activa cuando se acumula un backlog en una clave de ordenamiento individual porque la cantidad de mensajes producidos por segundo supera la cantidad de mensajes que el suscriptor puede procesar por segundo. Para mitigar las claves activas, usa las claves más detalladas que puedas y minimiza el tiempo de procesamiento por mensaje. También puedes supervisar la métrica
subscription/oldest_unacked_message_age
para detectar un valor en aumento, lo que podría indicar una clave activa.
Para obtener más información sobre cómo usar el orden de mensajes, consulta los siguientes temas de prácticas recomendadas:
Prácticas recomendadas para la mensajería ordenada en la publicación
Prácticas recomendadas para el envío de mensajes ordenados en la suscripción
Comportamiento del cliente suscriptor para el orden de los mensajes
Los clientes suscriptores reciben los mensajes en el orden en que se publicaron en una región específica. Pub/Sub admite diferentes formas de recibir mensajes, como clientes suscriptores conectados a suscripciones de extracción y de envío. Las bibliotecas cliente usan streamingPull (excepto PHP).
Para obtener más información sobre estos tipos de suscripciones, consulta Elige un tipo de suscripción.
En las siguientes secciones, se explica qué significa recibir mensajes en orden para cada tipo de cliente suscriptor.
Clientes suscriptores de StreamingPull
Cuando usas las bibliotecas cliente con streamingPull, debes especificar una devolución de llamada del usuario que se ejecute cada vez que un cliente suscriptor reciba un mensaje. Con las bibliotecas cliente, para cualquier clave de ordenamiento determinada, la devolución de llamada se ejecuta hasta completarse en los mensajes en el orden correcto. Si los mensajes se confirman dentro de esa devolución de llamada, todos los cálculos en un mensaje se producen en orden. Sin embargo, si la devolución de llamada del usuario programa otro trabajo asíncrono en los mensajes, el cliente suscriptor debe asegurarse de que el trabajo asíncrono se realice en orden. Una opción es agregar mensajes a una cola de trabajo local que se procesa en orden.
Clientes suscriptores de extracción
En el caso de los clientes suscriptores conectados a suscripciones de extracción, el orden de los mensajes de Pub/Sub admite lo siguiente:
Todos los mensajes de una clave de ordenamiento en PullResponse están en el orden correcto en la lista.
Solo puede haber un lote de mensajes pendiente para una clave de ordenamiento a la vez.
El requisito de que solo un lote de mensajes puede estar pendiente a la vez es necesario para mantener la entrega ordenada, ya que el servicio de 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.
Clientes suscriptores de envío
Las restricciones sobre la transferencia push son incluso más estrictas que las de la transferencia pull. 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. Cada mensaje se envía a un extremo de envío como una solicitud independiente. Por lo tanto, enviar las solicitudes en paralelo tendría el mismo problema que entregar varios lotes de mensajes para la misma clave de ordenamiento a los suscriptores de extracción de forma simultánea. Las suscripciones push podrían no ser una buena opción para los temas en los que los mensajes se publican con frecuencia con la misma clave de ordenamiento o en los que la latencia es extremadamente importante.
Exporta clientes suscriptores
Las suscripciones de exportación admiten mensajes ordenados. En el caso de las suscripciones a BigQuery, los mensajes con la misma clave de ordenamiento se escriben en su tabla de BigQuery en orden. En el caso de las suscripciones de Cloud Storage, es posible que no todos los mensajes con la misma clave de ordenamiento se escriban en el mismo archivo. Cuando están dentro del mismo archivo, los mensajes de una clave de ordenamiento están en orden. Cuando se distribuyen en varios archivos, los mensajes posteriores para una clave de ordenamiento pueden aparecer en un archivo con un nombre que tiene una marca de tiempo anterior a la marca de tiempo en el nombre del archivo con los mensajes anteriores.
Habilita el ordenamiento de mensajes
Para recibir los mensajes en orden, configura la propiedad de ordenamiento de mensajes de la suscripción de la que recibes mensajes. Recibir mensajes en orden puede aumentar la latencia. No puedes cambiar la propiedad de ordenamiento de mensajes después de crear una suscripción.
Puedes configurar la propiedad de ordenamiento de mensajes cuando creas una suscripción con la consola de Trusted Cloud , Google Cloud CLI o la API de Pub/Sub.
Console
Para crear una suscripción con la propiedad de ordenamiento de mensajes, sigue estos pasos:
- En la consola de Trusted Cloud , ve a la página Suscripciones.
Haz clic en Crear suscripción.
Ingresa un ID de suscripción.
Elige un tema del que quieras recibir mensajes.
En la sección Ordenamiento de mensajes, selecciona Ordenar mensajes con una clave de ordenamiento.
Haga clic en Crear.
gcloud
Para crear una suscripción con la propiedad de ordenamiento de mensajes, usa el comando gcloud pubsub subscriptions
create
y la marca --enable-message-ordering
:
gcloud pubsub subscriptions create SUBSCRIPTION_ID \ --enable-message-ordering
Reemplaza SUBSCRIPTION_ID por el ID de la suscripción.
Si la solicitud es exitosa, la línea de comandos muestra una confirmación:
Created subscription [SUBSCRIPTION_ID].
REST
Para crear una suscripción con la propiedad de ordenamiento de mensajes, envía una solicitud PUT
como la siguiente:
PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID Authorization: Bearer $(gcloud auth application-default print-access-token)
Reemplaza lo siguiente:
- PROJECT_ID: El ID del proyecto con el tema
- SUBSCRIPTION_ID: El ID de la suscripción
Especifica lo siguiente en el cuerpo de la solicitud:
{ "topic": TOPIC_ID, "enableMessageOrdering": true, }
Reemplaza TOPIC_ID por el ID del tema que deseas adjuntar a la suscripción.
Si la solicitud se realiza de forma correcta, la respuesta es la suscripción en formato JSON:
{ "name": projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID, "topic": projects/PROJECT_ID/topics/TOPIC_ID, "enableMessageOrdering": true, }
C++
Antes de probar esta muestra, sigue las instrucciones de configuración de C++ en la guía de inicio rápido sobre el uso de bibliotecas cliente. Si quieres obtener más información, consulta la documentación de referencia de la API de Pub/Sub para C++.
C#
Antes de probar esta muestra, sigue las instrucciones de configuración de C# en la guía de inicio rápido sobre el uso de bibliotecas cliente. Si quieres obtener más información, consulta la documentación de referencia de la API de Pub/Sub para C#.
Go
En el siguiente ejemplo, se usa la versión principal de la biblioteca cliente de Pub/Sub de Go (v2). Si aún usas la biblioteca de la versión 1, consulta la guía de migración a la versión 2. Para ver una lista de muestras de código de la versión 1, consulta las muestras de código obsoletas.
Antes de probar esta muestra, sigue las instrucciones de configuración de Go en la guía de inicio rápido sobre el uso de bibliotecas cliente. Si quieres obtener más información, consulta la documentación de referencia de la API de Pub/Sub para Go.
Java
Antes de probar esta muestra, sigue las instrucciones de configuración de Java en la guía de inicio rápido sobre el uso de bibliotecas cliente. Si quieres obtener más información, consulta la documentación de referencia de la API de Pub/Sub para Java.
Node.js
Antes de probar esta muestra, sigue las instrucciones de configuración de Node.js en la guía de inicio rápido sobre el uso de bibliotecas cliente. Si quieres obtener más información, consulta la documentación de referencia de la API de Pub/Sub para Node.js.
Node.js
Antes de probar esta muestra, sigue las instrucciones de configuración de Node.js en la guía de inicio rápido sobre el uso de bibliotecas cliente. Si quieres obtener más información, consulta la documentación de referencia de la API de Pub/Sub para Node.js.
Python
Antes de probar esta muestra, sigue las instrucciones de configuración de Python en la guía de inicio rápido sobre el uso de bibliotecas cliente. Si quieres obtener más información, consulta la documentación de referencia de la API de Pub/Sub para Python.
Ruby
En el siguiente ejemplo, se usa la versión 3 de la biblioteca cliente de Pub/Sub de Ruby. Si aún usas la biblioteca de la versión 2, consulta la guía de migración a la versión 3. Para ver una lista de muestras de código de Ruby v2, consulta las muestras de código obsoletas.
Antes de probar esta muestra, sigue las instrucciones de configuración de Ruby en la guía de inicio rápido sobre el uso de bibliotecas cliente. Si quieres obtener más información, consulta la documentación de referencia de la API de Pub/Sub para Ruby.
¿Qué sigue?
Lee la entrada de blog sobre la entrega ordenada.
Para continuar publicando mensajes en caso de errores que no se pueden reintentar, consulta Reintenta solicitudes con claves de ordenamiento.
Supervisa tu suscripción.
Obtén más información para publicar mensajes con claves de ordenamiento.