Les messages planifiés sont remis aux consommateurs à un moment précis plutôt qu'immédiatement. Utilisez-les pour créer des déclencheurs temporels dans les applications distribuées, tels que l'annulation automatique des commandes expirées, les notifications différées ou la planification de tâches périodiques.
Les messages planifiés et les messages différés fonctionnent de la même manière : le broker les conserve tous deux et les remet à un horodatage spécifié. Le terme « messages planifiés » utilisé ci-dessous couvre ces deux types.
Prérequis
Avant d'envoyer des messages planifiés, assurez-vous que :
Le paramètre
MessageTypede votre topic est défini surDelay. Les messages planifiés ne peuvent être envoyés qu'aux topics de typeDelay.L'horodatage de remise est postérieur à l'heure actuelle. Si l'horodatage est dans le passé ou dépasse la plage autorisée, le broker remet le message immédiatement.
-
L'horodatage de remise se situe dans la fenêtre de planification maximale correspondant à votre type d'instance :
Type d'instance Fenêtre de planification maximale Édition Standard (abonnement, paiement à l'utilisation ou serverless) et Édition Professionnelle serverless 7 jours Édition Professionnelle et Édition Enterprise Platinum (abonnement ou paiement à l'utilisation) 40 jours
Cas d'utilisation
Planification de tâches distribuées
Planifiez des messages avec différentes granularités temporelles pour remplacer les minuteurs traditionnels basés sur une base de données. Par exemple, déclenchez une tâche de nettoyage de fichiers quotidiennement à une heure fixe, ou envoyez une notification de rappel toutes les 2 minutes. Les messages planifiés éliminent la complexité liée à la gestion des tâches cron distribuées tout en offrant une meilleure évolutivité.

Gestion des délais d'expiration des tâches
Différez une action jusqu'à ce qu'une échéance soit dépassée. Par exemple, dans le commerce électronique, annulez une commande non payée 30 minutes après sa création au lieu d'interroger régulièrement une base de données pour vérifier le statut du paiement.

Par rapport à l'interrogation régulière d'une base de données pour détecter les enregistrements expirés, les messages planifiés offrent :
Une granularité temporelle flexible : déclenchez des tâches à n'importe quel intervalle, sans incréments de temps fixes ni besoin de logique de déduplication.
De meilleures performances : évitez les goulots d'étranglement liés aux analyses fréquentes de la base de données. L'infrastructure de messagerie gère la concurrence et permet une mise à l'échelle horizontale.
Fonctionnement de la planification
Horodatage de remise
L'heure de remise est exprimée sous forme d'horodatage Unix en millisecondes. Définissez-la sur le message à l'aide de setDeliveryTimestamp(). Le broker conserve le message jusqu'à ce que cet horodatage soit atteint.
Pour les messages planifiés, calculez l'heure de remise absolue : si l'heure actuelle est
2022-06-09 17:30:00et que vous souhaitez une remise à19:20:00, définissez l'horodatage sur1654773600000.Pour les messages différés, ajoutez un décalage relatif à l'heure actuelle : si l'heure actuelle est
2022-06-09 17:30:00et que vous souhaitez une remise après 1 heure, définissez l'horodatage sur1654770600000.
L'horodatage de remise ne peut pas être modifié ni annulé après l'envoi du message.
Cycle de vie des messages
Un message planifié traverse six étapes, de sa production à sa suppression :

| Étape | Description |
|---|---|
| Initialisation | Le producteur construit le message et l'envoie au broker. |
| Planifié | Le broker stocke le message dans un système de stockage basé sur le temps. Aucun index visible par le consommateur n'est encore créé. |
| Prêt pour la consommation | À l'horodatage de remise, le message passe dans le moteur de stockage standard et devient visible pour les consommateurs. |
| En cours de consommation | Un consommateur reçoit et traite le message. Si aucun accusé de réception n'arrive avant l'expiration du délai, le broker retente la remise. Pour plus d'informations, consultez Tentatives de consommation. |
| Validé | Le consommateur accuse réception du message. Le broker le marque comme consommé, mais ne le supprime pas immédiatement. |
| Supprimé | Le broker supprime le message de manière progressive lorsque la période de rétention expire ou que l'espace de stockage vient à manquer. Jusqu'à sa suppression, le message peut être reconsommé. Pour plus d'informations, consultez Stockage et nettoyage des messages. |
Limites
| Contrainte | Détail |
|---|---|
| Type de topic | Seuls les topics dont le paramètre MessageType est défini sur Delay acceptent les messages planifiés. |
| Précision temporelle | Précise à la milliseconde près. La granularité par défaut est de 1 000 ms. |
| Persistance | Les messages planifiés survivent aux redémarrages du broker. Toutefois, des exceptions du système de stockage ou des redémarrages peuvent entraîner de brefs retards de remise. |
| Annulation | Non prise en charge. Une fois envoyé, l'horodatage de remise ne peut plus être modifié ni révoqué. |
Envoi et consommation de messages planifiés
Les exemples suivants utilisent le SDK Java Apache RocketMQ 5.x. Chaque exemple de producteur définit un horodatage de remise avec setDeliveryTimestamp() ; c'est la seule différence par rapport à l'envoi d'un message normal. Pour la référence complète du SDK, consultez SDK Apache RocketMQ 5.x.
Assurez-vous que votre topic est créé avec le paramètreMessageTypedéfini surDelayavant d'exécuter ces exemples.
Bonnes pratiques
Échelonnez les heures de remise. Évitez de planifier un grand lot de messages pour exactement le même horodatage. Lorsque de nombreux messages partagent la même heure de remise, le broker doit tous les traiter simultanément, ce qui augmente la charge et peut retarder la remise. Répartissez les horodatages sur une plage lorsque cela est possible.
Intégrez une logique d'annulation dans les consommateurs. Comme il est impossible de révoquer ou de replanifier un message après son envoi, gérez l'annulation côté consommateur. Par exemple, lorsqu'un consommateur reçoit un message « annuler la commande non payée », vérifiez d'abord le statut actuel de la commande : si l'utilisateur a déjà payé, ignorez l'annulation.
FAQ
Puis-je annuler ou replanifier un message après l'avoir envoyé ?
Non. L'horodatage de remise est définitif une fois le message envoyé. Pour gérer les scénarios où une action planifiée devient inutile, intégrez cette logique dans votre consommateur. Par exemple, vérifiez le statut actuel de la commande avant d'annuler une commande non payée.
Que se passe-t-il si je définis une heure de remise dans le passé ?
Le broker le remet immédiatement, comme pour un message normal.
Pourquoi ne puis-je pas trouver mon message planifié dans la console ?
Les messages planifiés restent invisibles jusqu'à ce que l'horodatage de remise soit atteint. Vérifiez après cet instant : le message apparaît et devient disponible pour les consommateurs.