Acquittement de message
Un acquittement indique au courtier de messages qu’une livraison a été reçue ou traitée selon la règle convenue.
Un acquittement de message indique à un broker à quel moment il peut considérer une livraison comme terminée. Le sens de l’acquittement et l’étape à laquelle l’application l’envoie sont déterminants.
Dans RabbitMQ, un consommateur utilise un acquittement positif manuel tel que basic.ack pour confirmer son traitement au broker. Un publisher confirm confirme, lui, l’acceptation côté broker à l’émetteur. Cela n’établit pas que l’application destinataire a terminé sa tâche.
Entre l’enregistrement et l’acquittement
Dans un flux fictif, un service traite le message E-42, enregistre durablement la modification nécessaire en base de données, puis l’acquitte. S’il acquitte d’abord et s’arrête brutalement avant l’enregistrement, le broker peut déjà considérer la livraison comme terminée alors que la modification manque.
La situation inverse compte aussi : si la modification est enregistrée mais que l’acquittement se perd, une nouvelle livraison peut suivre. Avec les acquittements manuels, RabbitMQ remet les messages non acquittés en file après la fermeture d’une connexion ou d’un canal. Le service doit donc pouvoir gérer la répétition sans produire deux fois le même résultat métier.
L’acquittement automatique dans RabbitMQ n’attend pas la fin du travail de l’application. Le mode choisi doit correspondre à la protection souhaitée contre la perte de travail. L’acquittement du consommateur ne prouve pas non plus la réussite de tous les services en aval ou d’une notification externe.
Sources
Termes associés
- File de messagesUne file de messages conserve les messages en attente de leur prise en charge par un consommateur.
- Inbox transactionnelleUne inbox transactionnelle utilise des enregistrements durables de messages pour protéger le traitement local contre les livraisons en double.
- Délai aléatoire avant réessaiLe jitter fait varier aléatoirement les délais pour étaler les nouvelles tentatives de plusieurs clients.
- Espace client de testUn espace client logiquement délimité d’une application multilocataire, configuré pour les vérifications.
- Rejeu de webhookLe rejeu de webhook renvoie une notification déjà envoyée. La reprise volontaire et les attaques par rejeu nécessitent des contrôles différents.
- Clé d’idempotenceUne clé d’idempotence identifie les répétitions d’une même requête. Son effet dépend du périmètre, de la conservation et des règles de l’API.
Articles sur le sujet








Interfaces & intégration avec ASES
ERP, CRM et boutique bien connectés

