Lors de la création d'une tâche DTS pour synchroniser ou migrer des données vers une instance Apache Kafka, choisissez un mécanisme d'accusé de réception (acks) afin de stocker durablement les messages livrés. Ce paramètre définit le nombre de réplicas du broker qui doivent confirmer la réception avant que DTS ne considère le message comme livré, et détermine le compromis entre débit et durabilité des données.
DTS prend en charge trois mécanismes d'acks, chacun correspondant à une garantie de livraison standard de Kafka.
Comparaison des mécanismes
| Mécanisme | Débit | Durabilité des données | Recommandé pour |
|---|---|---|---|
| Ne pas attendre de confirmation | Le plus élevé | La plus faible : les messages peuvent être perdus silencieusement | Collecte de journaux, données de surveillance |
| Attendre la confirmation du nœud principal | Modéré | Modérée : perte possible si le leader tombe en panne avant la fin de la réplication | La plupart des scénarios (recommandé) |
| Attendre la confirmation de tous les ISR | Le plus faible | La plus élevée : perte uniquement en cas de défaillance de tous les réplicas | Transactions financières, traitement des commandes |
Détails des mécanismes
Ne pas attendre de confirmation
Le producteur envoie un message sans attendre de réponse du broker. Le message est considéré comme envoyé dès sa sortie du producteur.
Débit : Le plus élevé (aucune attente liée à l'aller-retour réseau).
Risque de perte de données : Élevé. Le producteur ne peut pas détecter les échecs de livraison.
Utilisation recommandée : Lorsque la fiabilité n'est pas critique, par exemple pour la collecte de journaux ou les données de surveillance.
Attendre la confirmation du nœud principal
Le producteur attend que le réplica leader écrive le message dans son journal local avant que le broker ne renvoie une réponse. Les réplicas followers n'ont pas besoin de confirmer.
Débit : Modéré.
Risque de perte de données : Modéré. Si le leader tombe en panne après avoir accusé réception du message mais avant que les followers ne le répliquent, le message est perdu.
Utilisation recommandée : Pour équilibrer performances et fiabilité. Ce choix convient à la plupart des scénarios. DTS recommande ce mécanisme.
Attendre la confirmation de tous les ISR
Le producteur attend que tous les réplicas synchronisés (ISR) accusent réception du message avant que le broker ne réponde.
Débit : Le plus faible.
Risque de perte de données : Le plus faible. Les messages ne sont perdus que si tous les réplicas tombent en panne.
Utilisation recommandée : Lorsque la perte de données est inacceptable, par exemple pour les transactions financières ou le traitement des commandes.
Configuration du mécanisme
Accédez à l'étape Configure Objects d'une tâche de synchronisation ou de migration de données DTS, puis sélectionnez Message acknowledgement mechanism.