Parcours de conception d'un ordonnanceur de tâches : baux, nouvelles tentatives, clés d'idempotence et table de file

Objectif

Exécuter des tâches de fond et des planifications récurrentes avec une exécution au moins une fois, des nouvelles tentatives bornées et sans effets de bord dupliqués, en utilisant une table de base de données avant d'adopter un broker.

Prérequis

Une base de données relationnelle partagée par tous les workers, des gestionnaires que l'on peut rendre idempotents, et une seule horloge : les horodatages viennent de la base de données, pas des hôtes des workers.

Étapes

1. Contraintes : une tâche s'exécute au moins une fois et peut s'exécuter à nouveau après un plantage ; une planification se déclenche une fois par créneau même avec plusieurs instances d'ordonnanceur ; une tâche défaillante ne doit pas bloquer les autres.
2. Composants : une table job faisant office de file ; des workers qui réclament, exécutent et terminent les tâches ; un ordonnanceur qui transforme les planifications en tâches ; un reaper pour les baux expirés ; une liste de lettres mortes (dead-letter).
3. Modèle de données : job(id, type, payload, idempotency_key unique, status: ready|running|done|failed|dead, run_at, attempts, max_attempts, locked_by, locked_until, last_error, created_at) ; schedule(id, job_type, cron, next_run_at, last_slot) ; un index sur (status, run_at). Pour les tâches planifiées, la clé d'idempotence est schedule_id + slot, si bien qu'une seconde instance d'ordonnanceur mettant en file le même créneau ne fait rien.
4. Réclamation : SELECT ... WHERE status = 'ready' AND run_at <= now() ORDER BY run_at LIMIT 1 FOR UPDATE SKIP LOCKED, puis passer à running, définir locked_by et locked_until = now() + lease, et valider. La documentation PostgreSQL indique qu'avec SKIP LOCKED, les lignes qui ne peuvent pas être verrouillées immédiatement sont ignorées, et que cela peut servir à éviter la contention de verrous avec plusieurs consommateurs accédant à une table de type file. Les gestionnaires longs prolongent le bail par un heartbeat.
5. Nouvelles tentatives : en cas d'échec, définir run_at = now() + backoff(attempts) avec du jitter et remettre la ligne à ready, jusqu'à ce que max_attempts la fasse passer à dead ; les erreurs d'infrastructure (base de données injoignable) ne comptent pas comme des tentatives. Le gestionnaire vérifie son propre effet avant d'agir (une ligne déjà écrite, un identifiant de message déjà enregistré), car l'ordonnanceur ne peut pas garantir une exécution unique.
6. Modes de défaillance : un worker meurt en détenant un bail (le reaper réinitialise la ligne après locked_until et le gestionnaire s'exécute à nouveau) ; des pics en début d'heure (un décalage par planification étale run_at) ; une tâche empoisonnée (max_attempts, lettre morte, alerte) ; la table qui croît sans limite (archiver les lignes done selon une planification) ; un worker dont l'horloge dérive (n'utiliser que l'heure de la base de données).
7. Mesurer : l'âge de la plus ancienne tâche prête, les tâches en cours par type, la distribution des tentatives, les expirations de bail par heure, le nombre de lettres mortes, les créneaux de planification manqués.
8. Pas en priorité : un broker de messages, les priorités et l'équité par tenant, les graphes de workflow, les garanties d'exactement une fois.

Résultat attendu

Un plantage, où qu'il survienne, retarde le travail plutôt que de le perdre ou de le dupliquer, et l'historique de chaque tâche tient dans une ligne qui explique son état.

Limites et base de vérification

Conception proposée, aucune mesure. Une table de file convient à des volumes modérés ; le passage à un broker est une décision ultérieure, guidée par l'âge de file mesuré et les attentes de verrous.