Communication asynchrone

La communication sur un Stream est asynchrone et bidirectionnelle. Votre client envoie des enregistrements en continu sans attendre la confirmation de chacun d'eux, et le serveur renvoie des accusés de réception sur la même connexion à mesure que les enregistrements deviennent durables. Ce découplage est ce qui permet à un client unique de maintenir un throughput élevé : il continue d'envoyer des données pendant que les accusés de réception arrivent en arrière-plan.

Offsets et boucle d'accusé de réception

Chaque soumission sur un stream, qu'il s'agisse d'un enregistrement unique ou d'un batch, se voit attribuer un offset logique qui marque sa position dans ce stream. Plutôt que d'accuser réception de chaque soumission individuellement, le serveur signale la progression cumulative de la durabilité via l'offset validé le plus élevé qu'il a rendu durable jusqu'à présent. Comme les offsets sont ordonnés, un accusé de réception confirme cette soumission ainsi que toutes les précédentes.

Il s'agit de 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 en cours de transfert.
2. Le serveur conserve les enregistrements de manière durable et renvoie périodiquement l'offset validé le plus élevé.
3. À la réception de cet offset, le client purge en toute sécurité chaque enregistrement mis en mémoire tampon jusqu'à ce point, car ces enregistrements sont désormais durables.

Lorsque vous utilisez un SDK Zerobus Ingest, le SDK exécute cette boucle pour vous. Il suit les offsets, gère le tampon en cours de transfert et traite les accusés de réception en arrière-plan pendant que votre producteur continue d’envoyer des données. Vous n’implémentez pas la boucle vous-même. Ce que vous contrôlez éventuellement, c’est la manière dont vous observez la durabilité :

• Continuez l'envoi ; le SDK traite les accusés de réception au fur et à mesure de leur arrivée.
• Bloquez sur un offset uniquement lorsque votre application doit attendre qu'un enregistrement spécifique soit durable. Voir ci-dessous.
• Enregistrez un callback de confirmation pour réagir aux confirmations et aux erreurs de manière asynchrone, sans blocage. Voir Callbacks de confirmation.

Vous ne devriez implémenter vous-même la boucle de suivi des offsets et de mise en mémoire tampon que si vous créez un client personnalisé qui n'utilise pas de SDK.

Le tampon de transit est limité par une limite configurable d'enregistrements en transit. L'ingestion est asynchrone jusqu'à ce que le tampon soit plein ; à ce stade, les appels d'ingestion sont bloqués jusqu'à ce que les accusés de réception arrivent et libèrent de l'espace. Ajustez la limite pour votre charge de travail et notez que les enregistrements mis en tampon consomment de la mémoire client pendant leur transit. Pour l'option et son default, consultez le repository du SDK Zerobus.

Si la connexion est interrompue, les enregistrements toujours présents dans le tampon en cours de transfert (ceux au-delà du dernier offset validé) n'ont pas été confirmés comme durables et peuvent donc être rejoués. Voir Modèles de récupération et de nouvelle tentative.

L'accusé de réception confirme la durabilité, et non la possibilité d'interrogation. Un offset validé signifie que ces enregistrements sont persistés de manière durable et ne seront pas perdus. Zerobus Ingest matérialise les enregistrements durables dans la table Delta lors d'une étape distincte peu après, moment à partir duquel les données deviennent interrogeables en environ 5 secondes. Pour en savoir plus sur la latence, consultez Latence.

Attente d'un enregistrement par rapport à la maximisation du throughput

Vous attendez l'offset d'un enregistrement lorsque votre application doit bloquer toute exécution ultérieure jusqu'à ce que cet enregistrement spécifique soit connu comme étant durable, par exemple avant de confirmer le travail à un système en amont. L'attente concerne la synchronisation au niveau de l'application, et non une exigence de durabilité. Un enregistrement devient durable via la boucle d'accusé de réception, que vous bloquiez ou non dessus.

Le blocage a un coût en termes de throughput :

• L'attente après chaque enregistrement transforme l'ingestion en un workflow effectivement synchrone. Bloquer chaque message avant d'envoyer le suivant empêche le client d'atteindre le throughput complet de Zerobus Ingest.
• L’ingestion à haut throughput est continue et asynchrone. Le client continue d’envoyer des enregistrements pendant que les accusés de réception arrivent pour des groupes d’enregistrements précédents, plutôt que de faire une pause à chaque fois. Attendez un offset spécifique uniquement aux points de contrôle où votre application a réellement besoin de cette garantie, ou utilisez un callback d’accusé de réception pour suivre la progression sans bloquer.

Pour les méthodes d’ingestion, les moments où bloquer sur un offset et le fonctionnement des rappels d’accusé de réception, consultez Blocage et accusé de réception des messages.

Mise en ordre sur un Stream

Les accusés de réception et les offsets sont par stream : l'ordre est garanti au sein d'un seul stream, et non globalement entre les streams. Pour savoir comment fonctionne l'ordre par stream et comment le concevoir, consultez les garanties d'ordre.