Communication asynchrone

La communication sur un flux est asynchrone et bidirectionnelle. Votre client envoie les enregistrements en continu sans attendre la confirmation de chacun, et le serveur renvoie des accusés de réception sur la même connexion à mesure que les enregistrements sont rendus persistants. C’est ce découplage qui permet à un seul client de maintenir un débit élevé : il continue à envoyer des données pendant que les accusés de réception arrivent en arrière-plan.

Décalages et boucle d’accusé de réception

Chaque soumission sur un flux, qu’il s’agisse d’un enregistrement unique ou d’un lot, se voit attribuer un décalage logique qui marque sa position dans ce flux. Plutôt que d’accuser réception de chaque envoi individuellement, le serveur indique la progression cumulative de durabilité par l’intermédiaire du décalage validé le plus élevé qu’il a rendu durable jusqu’à présent. Comme les décalages sont ordonnés, un accusé de réception confirme cet envoi ainsi que tous les précédents.

C’est la boucle d’accusé de réception, et c’est ce qui maintient la connexion à la fois rapide et fiable :

1. Le client envoie les enregistrements et les conserve dans un tampon local des données en cours de transmission.
2. Le serveur conserve les enregistrements de façon durable et renvoie périodiquement le décalage le plus élevé confirmé.
3. À la réception de cet offset, le client purge en toute sécurité tous les enregistrements en mémoire tampon jusqu’à cet offset, car ces enregistrements sont désormais durables.

Lorsque vous utilisez un SDK Zerobus Gest, le SDK exécute cette boucle pour vous. Il suit les décalages, maintient le tampon local en cours de transmission et traite les accusés de réception en arrière-plan pendant que votre producteur continue de pousser. On ne met pas en place la boucle soi-même. Ce que vous contrôlez éventuellement, c’est la façon dont vous observez la durabilité :

• Continue d’envoyer ; le SDK traite les accusés de réception au fur et à mesure qu’ils arrivent.
• Ne bloquez sur un décalage que lorsque votre application doit attendre qu’un enregistrement spécifique ait été écrit de façon durable. Voir ci-dessous.
• Enregistrer une fonction de rappel d’accusé de réception pour réagir aux confirmations et aux erreurs de manière asynchrone, sans bloquer l’exécution. Voir Rappels d’accusé de réception.

Vous n’implémenteriez vous-même la boucle de suivi et de mise en mémoire tampon que si vous construisez un client personnalisé qui n’utilise pas de SDK.

Le tampon en cours de transmission est restreint par une limite configurable d’enregistrement en cours de transmission. L’ingestion est asynchrone jusqu’à ce que le tampon se remplisse ; à ce moment-là, les opérations d’ingestion sont bloquées jusqu’à ce que les accusés de réception arrivent et libèrent de la place. Ajustez la limite pour votre charge de travail, et notez que les enregistrements en mémoire tampon consomment la mémoire client pendant qu’ils sont en vol. Pour connaître l’option et sa valeur par défaut, consultez le dépôt Zerobus SDK.

Si la connexion est interrompue, les enregistrements encore dans le tampon en cours de transmission (ceux qui ont dépassé le dernier décalage confirmé) n’ont pas été confirmés durables, ils peuvent donc être rejoués. Voir les schémas de récupération et de réessayage.

L’accusé de réception confirme la durabilité, pas la possibilité de faire des questions. Un décalage validé signifie que ces enregistrements ont été conservés de manière durable et ne seront pas perdus. Zerobus Ingest matérialise des enregistrements durables dans la table Delta comme étape séparée peu après, moment où les données deviennent interrogables en environ 5 secondes. Pour en savoir plus sur la latence, voir Latence.

Attendre un enregistrement versus maximiser le débit

Vous attendez le décalage d’un enregistrement lorsque votre application doit bloquer l’exécution supplémentaire jusqu’à ce que cet enregistrement spécifique soit reconnu comme durable, par exemple avant qu’il reconnaisse le travail dans un système en amont. L’attente concerne la synchronisation au niveau de l’application, pas une exigence de durabilité. Un enregistrement devient durable à travers la boucle d’accusé de réception, que vous le bloquiez ou non.

Le blocage a un coût en termes de débit :

• Attendre après chaque enregistrement transforme l’ingestion en un flux de travail pratiquement synchrone. Bloquer chaque message avant l’envoi du suivant empêche le client d’atteindre le débit complet de Zerobus Ingest.
• L’ingestion à haut débit est continue et asynchrone. Le client continue d’envoyer des enregistrements pendant que les accusés de réception arrivent pour des groupes d’anciens enregistrements, au lieu de s’arrêter sur chacun d’eux. Attendez un décalage spécifique uniquement aux points de contrôle où votre application a vraiment besoin de cette garantie, ou utilisez un rappel d’accusé de réception pour suivre l’avancement sans bloquer.

Pour les méthodes d’ingestion, quand bloquer sur un décalage et comment fonctionnent les rappels d’accusé de réception, voir Blocage et accusé de réception des messages.

Classement dans un flux

Les accusés de réception et les décalages sont effectués par flux : le classement est garanti au sein d’un seul flux, et non globalement entre les flux. Pour savoir comment fonctionne la commande par flux et comment la concevoir en conséquence, voir Garanties de commande.