Descripción general de las colas de Spanner

Las colas de Spanner proporcionan mensajería transaccional para ayudarte a administrar el trabajo asíncrono. La función combina esta capacidad con la escalabilidad y la confiabilidad de Spanner, lo que te permite compilar aplicaciones basadas en eventos. Las colas de Spanner usan un modelo de extracción para el consumo de mensajes, que expone una interfaz de SQL para que los receptores soliciten y reciban mensajes.

Elige entre las colas y los flujos de cambios de Spanner

La siguiente comparación proporciona orientación para elegir el mecanismo adecuado para la propagación de datos y el procesamiento asíncrono.

Colas de Spanner

Ideal para

  • Notificaciones de eventos transaccionales
  • Ejecución de trabajo programada para el futuro
  • Lógica de confirmación por mensaje

Características clave

  • Cargas útiles de mensajes pequeñas y definidas por el usuario
  • Modelo de extracción para el consumo de mensajes
  • Se ajusta según la capacidad de procesamiento de la instancia de Spanner

Flujos de cambios de Spanner

Ideal para

  • Replicación de datos de alta capacidad de procesamiento
  • Sincronización de cachés o índices descendentes
  • Registro de auditoría de cada cambio en la base de datos

Características clave

  • Captura todos los fragmentos de la grabación (hasta 10 MB).
  • Transmisión basada en extracciones con tokens de partición
  • Incluye latidos y puntos de control

Ventajas principales

Las colas de Spanner ofrecen varias ventajas:

  • Integrado: La mensajería está integrada en la base de datos. Esto elimina la necesidad de aprovisionar, administrar y filtrar datos a una infraestructura de mensajería separada, lo que simplifica la arquitectura de la aplicación y reduce los costos generales.
  • Transaccional: Puedes enviar y confirmar mensajes de forma atómica dentro de una transacción de Spanner junto con otras escrituras de la base de datos. Los mensajes en cola se revierten y no están disponibles para la entrega si falla la transacción.
  • Duraderos: Los mensajes que no se pueden entregar se almacenan en la base de datos. Spanner intenta continuamente la entrega con una espera exponencial hasta que se confirma o borra el mensaje de forma explícita.
  • Consultables: Los mensajes se compilan en las mismas primitivas que las tablas de Spanner y se almacenan como filas. Puedes consultarlas, unirlas o filtrarlas como tablas estándar.
  • Escalable: Se creó con la misma escalabilidad que las tablas de Spanner, por lo que el procesamiento de mensajes se ajusta junto con el resto de la base de datos.
  • Confiables: Las colas de Spanner heredan todas las primitivas de alta disponibilidad de Spanner, lo que hace que el envío y el procesamiento de mensajes sean tolerantes a errores y resistentes a fallas zonales o regionales.
  • Programables: Los mensajes se pueden programar para su entrega en el futuro, lo que te permite diferir la ejecución de tareas a una marca de tiempo futura específica.
  • Atómico: El envío de mensajes (APIs de INSERT o de mutación) y la confirmación (APIs de DELETE o de mutación) se ejecutan de forma atómica dentro de las transacciones, lo que garantiza la coherencia con el estado de la base de datos.
  • Extensibles: Los arrendamientos de mensajes se pueden extender para admitir tiempos de procesamiento extremadamente largos combinando mecanismos de arrendamiento manual y de entrega futura.

Casos de uso

Las filas de Spanner son útiles para organizar tareas diferidas dentro de una transacción. A continuación, se muestran algunos ejemplos comunes:

  • Aplazamiento de trabajo computacionalmente pesado: Un sitio web para compartir fotos podría necesitar realizar un procesamiento de imágenes intensivo cuando se sube una foto nueva. La transacción que escribe los nuevos metadatos de la foto puede escribir simultáneamente un mensaje en la cola. Más adelante, un receptor de la cola recupera el mensaje, realiza el procesamiento y actualiza los metadatos de forma transaccional.
  • Aplazamiento de actualizaciones transaccionales grandes: En una app de calendario, invitar a un grupo grande a una reunión en una sola transacción puede causar conflictos de bloqueo y latencias finales. En cambio, la transacción que crea la entrada del calendario puede agregar una entrada de la cola para cada invitado, lo que permite que un receptor envíe las invitaciones de forma individual.
  • Programación de tareas para el futuro: Una empresa de software como servicio (SaaS) que ofrece una prueba gratuita de 30 días puede aprovisionar los recursos del usuario y, al mismo tiempo, poner en cola un mensaje programado para entregarse en 30 días. Luego, un trabajador recibe el mensaje y ejecuta la lógica de vencimiento de la prueba.
  • Deferir el trabajo a sistemas externos: Después de que un usuario se registra, es posible que una aplicación necesite enviar un correo electrónico de bienvenida solo si el registro de la base de datos se realiza correctamente. La transacción de registro puede agregar una entrada a una fila, lo que permite que un trabajador invoque una API de correo electrónico externa más adelante.
  • Organización de canalizaciones de varios pasos: En un sistema de administración de pedidos, completar un pedido implica varios pasos que podrían fallar de forma independiente. Al representar cada paso como un mensaje de cola, el sistema puede crear puntos de control del estado de la canalización y continuar desde el punto de falla.

Flujo de trabajo

Un flujo de trabajo típico para las colas de Spanner sigue estos pasos:

  • Crea una cola: Define una cola con DDL, de forma similar a una tabla. Debe incluir una columna Payload (payload en PostgreSQL) y una clave principal.
  • Enviar mensajes: Poner en cola mensajes con DML estándar (INSERT) o APIs de mutación, de forma transaccional con otras operaciones de bases de datos
  • Recibe mensajes: Usa la API de ExecuteStreamingSQL para llamar a una función con valores de tabla (TVF) llamada RECEIVE_QUEUE_NAME(). Esta función transmite mensajes a tu cliente como una consulta de larga duración.
  • Procesa mensajes: Consume los mensajes que recibes del TVF con la lógica de tu aplicación.
  • Confirmar mensajes: Quita mensajes de la cola con DML (DELETE) o APIs de mutación (como ack). Por lo general, esto se hace después de que se completa el procesamiento, dentro de una transacción.
  • Administrar asignaciones de tiempo: Administra las asignaciones de tiempo de los mensajes para garantizar que las colas de Spanner no vuelvan a entregar mensajes cuando se agote el tiempo de asignación. El método más común es usar la TVF RENEWLEASE_QUEUE_NAME().

Además, ten en cuenta estos comportamientos principales de las colas de Spanner:

  • Entrega al menos una vez: Común a la mayoría de los sistemas de colas basados en la nube, Spanner promete la entrega al menos una vez. Las reentregas se pueden mitigar extendiendo las asignaciones de tiempo.
  • Confirmación a lo sumo una vez: Dado que la confirmación de un mensaje se realiza a través de una transacción, la semántica ACID de Spanner garantiza que un mensaje solo se confirme una vez. Sigue los métodos de la página Procesamiento de tipo “exactamente una vez” y confirmación de recepción de tipo “como máximo una vez” para implementar correctamente la confirmación de recepción de tipo “como máximo una vez”.

Limitaciones

Las colas de Spanner tienen las siguientes limitaciones:

  • Receptores máximos: Hay un límite de 1,000 consultas de recepción activas con los mismos argumentos por fila.
  • Límite de cuota de TVF de recepción simultánea: Existe un límite de cuota de 2,000 TVF de recepción simultánea por proyecto y por región. Para aumentar el límite de cuota, completa el formulario Solicita un aumento de cuota para tu proyecto de Cloud Spanner.
  • División manual: La API de AddSplits no es compatible con las colas. La distribución de la carga de trabajo depende por completo de la división basada en la carga. Se recomienda la intercalación de la cola en una tabla para que los usuarios puedan agregar puntos de división a la tabla.
  • Cumplimiento de la partición geográfica: Las filas particionadas geográficamente no cumplen con la residencia de datos después de ejecutar una operación DROP PARTITION.
  • Límites de recuento de colas: Las instancias están limitadas a 100 colas para instancias con 1 o más nodos. El límite se reduce proporcionalmente para las instancias detalladas (por ejemplo, las instancias con 200 unidades de procesamiento se limitan a 20 colas).
  • Eliminar y volver a crear una fila: No se admite por completo eliminar y volver a crear una fila con el mismo nombre. Es posible que la TVF de RECEIVE para la cola tarde en "restablecerse" antes de que se puedan volver a recibir mensajes con el mismo nombre.
  • Nombres de columnas de PostgreSQL: Spanner expone las columnas deliver_time y DeliverTime para la hora de entrega de un mensaje. Te recomendamos que uses la columna deliver_time para alinearte con las convenciones de nomenclatura estándar de PostgreSQL y porque la columna DeliverTime se ocultará del esquema de información en una versión futura.
  • Esquema con nombre: No se pueden crear colas en esquemas con nombre.

¿Qué sigue?