Les besoins asynchrone sont partout dans les projets web afin de répondre plus vite à l'utilisateur mais également pour faciliter la gestion d'erreur et recommencer un traitement. Depuis que j'ai découvert RabbitMQ, je n'ai cessé de le mettre en place dans les projets allant d'utilisation simple à des utilisations plus complexe en passant par l'administration du serveur. Cette expérience je la retranscris dans les articles suivant.
Parfois le traitement d'un message provoque une erreur. Dans ce cas, il est courant de déplacer ce message dans une autre queue pour réessayer de le traiter plus tard. Tout cela peut être automatisé dans RabbitMQ avec les option DLX/DLK et l'application d'un TTL. Mais attention de ne pas créer une boucle infinie de tentative de traitement, dans cet article je vais vous présenter x-death pour contrôler le nombre de réessaie.
Retour d’expérience sur ma première fois en tant que speaker, c'était à Montpellier pour le PHP Tour 2018 organisé par l'AFUP.
Publier un message dans RabbitMQ est très facile, malheureusement RabbitMQ ne fournis en retour aucune information sur la réussite ou non de la publication dans une queue. Une simple faute de frappe dans la routing key et le message sera perdu à jamais sans pouvoir en être informé. L'option Alternate Exchange permet de récupérer les messages dans une queue spécifique.
RabbitMQ est rapide, parfois un peu trop par rapport au reste de l'infrastructure. Un retard de réplication en base de donnée peut planter la consommation d'un message. Je montre mon cheminement pour gérer ce problème et l'utilisation des options dead letter exchange et dead letter routing key pour temporiser le traitement d'un message.
Astuce pour débloquer le lancement de RabbitMQ sur un serveur Debian, si vous avez déplacé le dossier de logs dans un montage temporaire.