Dead-Letter Queue
File d'attente des messages non traités
Une file de messages en échec conserve les messages qu'une file source n'a pas pu traiter après ses tentatives autorisées. Les personnes peuvent examiner l'échec avant une nouvelle tentative contrôlée.
source queue + receive count > limit -> DLQ + configured monitor -> alert -> inspect/fix -> controlled redriveemail_804✓la file principale continueemail_803!mauvaise adressedead/email_803→inspecter en premiersource queue + receive count > limit -> DLQ + configured monitor -> alert -> inspect/fix -> controlled redriveJOBUn autre exemple
L'importation de la ligne `row-73` échoue cinq fois car sa date est mal formatée. Amazon SQS déplace le message vers une DLQ. L'alarme configurée par l'équipe avertit alors un opérateur. Après avoir corrigé le parseur, l'opérateur renvoie un petit lot à un rythme sûr.
Parties principales
- 01File d'attente source
- 02Limite de tentative
- 03raison de l'échec
- 04Message de la file d'attente des messages non traités
- 05Alerte et propriétaire
- 06Inspecter, corriger et redémarrer
Utilisez-le lorsque
Utilisez une DLQ lorsque des échecs répétés doivent arrêter le cycle dans la file principale. Conservez la raison, la source, le nombre de tentatives, l’âge du message et un chemin de redirection sécurisé.
Ne l'utilisez pas lorsque
Ne déplacez pas un message après le premier échec court, ignorez une DLQ en croissance, ou relancez avant de résoudre la cause. Supprimer un élément peut également rompre un flux nécessitant un ordre strict.
Nom utilisé dans le code
source queue + receive count > limit -> DLQ + configured monitor -> alert -> inspect/fix -> controlled redrive Avant d'expédier
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Complete the task with File d'attente des messages non traités (Dead-Letter Queue). User context: L'importation de la ligne `row-73` échoue cinq fois car sa date est mal formatée. Amazon SQS déplace le message vers une DLQ. L'alarme configurée par l'équipe avertit alors un opérateur. Après avoir corrigé le parseur, l'opérateur renvoie un petit lot à un rythme sûr. Technical concept or control: File d'attente des messages non traités (Dead-Letter Queue). Why it fits: Utilisez une DLQ lorsque des échecs répétés doivent arrêter le cycle dans la file principale. Conservez la raison, la source, le nombre de tentatives, l’âge du message et un chemin de redirection sécurisé. Do not use it when: Ne déplacez pas un message après le premier échec court, ignorez une DLQ en croissance, ou relancez avant de résoudre la cause. Supprimer un élément peut également rompre un flux nécessitant un ordre strict. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): Aucun standard officiel unique ne régit l’ensemble du terme. Sa signification peut varier selon les équipes, plateformes ou frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Vérifiez cette demande
Review how File d'attente des messages non traités (Dead-Letter Queue) is used now. Definition: Une file de messages en échec conserve les messages qu'une file source n'a pas pu traiter après ses tentatives autorisées. Les personnes peuvent examiner l'échec avant une nouvelle tentative contrôlée. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.