Comunicación asíncrona

La comunicación en un flujo es asincrónica y bidireccional. Tu cliente envía registros continuamente sin esperar a que se confirme cada uno, y el servidor envía acuses de recibo por la misma conexión a medida que los registros se vuelven duraderos. Este desacoplamiento es lo que permite que un solo cliente mantenga un alto rendimiento: sigue empujando mientras los acuses de recibo llegan en segundo plano.

Offsets y el bucle de confirmación

A cada envío en un flujo, ya sea un registro individual o un lote, se le asigna un desplazamiento lógico que marca su posición en ese flujo. En lugar de reconocer cada envío individualmente, el servidor informa del progreso acumulado de durabilidad a través del mayor offset comprometido que ha hecho duradero hasta ahora. Como los desajustes están ordenados, un acuse de recibo confirma esa entrega y todos los anteriores.

Este es el bucle de acuse de reconocimiento, y es lo que mantiene la conexión rápida y fiable:

1. El cliente envía los registros y los mantiene en un buffer local durante el vuelo.
2. El servidor mantiene registros persistentes de forma duradera y periódicamente envía de vuelta el offset comprometido más alto.
3. Al recibir ese desplazamiento, el cliente elimina de forma segura todos los registros almacenados en el búfer hasta ese punto, porque esos registros ya se han almacenado de forma persistente.

Cuando usas un SDK de Ingesta de Zerobus, el SDK ejecuta este bucle por ti. Rastrea los desfases, mantiene el búfer de solicitudes en curso y procesa las confirmaciones de recepción en segundo plano mientras tu productor sigue enviando. No implementas el bucle tú mismo. Lo que opcionalmente controlas es cómo observas la durabilidad:

• Sigue enviando; el SDK procesa los acuses de recibo a medida que llegan.
• Bloquea un offset solo cuando tu solicitud deba esperar a que un registro específico sea duradero. Consulte a continuación.
• Registrar una llamada de reconocimiento para reaccionar a confirmaciones y errores de forma asíncrona, sin bloquear. Consulta las devoluciones de llamada de confirmación.

Solo tendrías que implementar tú mismo el seguimiento de offsets y el almacenamiento en búfer si creas un cliente personalizado que no utilice un SDK.

El búfer en vuelo está limitado por un límite configurable de registros en vuelo. La ingestión es asíncrona hasta que el búfer se llena; en ese momento, las llamadas de ingestión se bloquean hasta que se reciben las confirmaciones y se libera espacio. Ajusta el límite para tu carga de trabajo, y ten en cuenta que los registros almacenados en búfer consumen memoria del cliente mientras están en tránsito. Para la opción y su predeterminado, consulta el repositorio Zerobus SDK.

Si la conexión se interrumpe, los registros que aún están en el buffer en vuelo (los que superan el último desplazamiento comprometido) no se han confirmado como duraderos, por lo que pueden reproducirse. Consulta patrones de recuperación y reintentos.

El reconocimiento confirma la durabilidad, no la posibilidad de consulta. Un offset comprometido significa que esos registros se mantienen de forma duradera y no se perderán. Zerobus Ingest materializa los registros duraderos en la tabla Delta como un paso separado poco después, momento en el que los datos se pueden consultar en aproximadamente 5 segundos. Para más información sobre la latencia, véase Latencia.

Esperar un registro frente a maximizar el rendimiento

Esperas al desplazamiento de un registro cuando tu aplicación debe bloquear la ejecución adicional hasta que se sepa que ese registro específico es duradero, por ejemplo, antes de reconocer el trabajo a un sistema aguas arriba. La espera se refiere a la sincronización a nivel de aplicación, no a un requisito de durabilidad. Un registro pasa a ser persistente a través del ciclo de confirmación, bloquees o no en ello.

El bloqueo tiene un coste de rendimiento:

• Esperar después de cada registro convierte la ingestión en un flujo de trabajo prácticamente síncrono. Bloquear en cada mensaje antes de enviar el siguiente impide que el cliente alcance el rendimiento completo de Zerobus Ingest.
• La ingesta de alto rendimiento es continua y asincrónica. El cliente sigue enviando registros mientras llegan las confirmaciones de recepción de grupos de registros previos, en lugar de detenerse con cada uno. Espera un desplazamiento específico solo en los puntos de control donde tu aplicación realmente necesite esa garantía, o usa una llamada de reconocimiento para seguir el progreso sin bloquear.

Para conocer los métodos de ingestión, cuándo bloquearse en un desplazamiento y cómo funcionan las funciones de devolución de llamada de confirmación, consulte Bloqueo y confirmación de mensajes.

Ordenación en un flujo

Las confirmaciones y los desplazamientos son específicos de cada flujo: se garantiza el orden dentro de un único flujo, no de forma global entre distintos flujos. Para saber cómo funciona la ordenación por flujo y cómo diseñar en función de ella, consulta Garantías de ordenación.