Amélioration du système de queue avec NSQ

Yama CI utilise maintenant NSQ pour la gestion des queues de tâches à exécuter. Cela permet entre autres de pouvoir conserver la queue en cas de problème software ou hardware, mais surtout de se reposer sur une base simple mais solide et évolutive.

NSQ est très facile d’utilisation : c’est un simple exécutable, nsqd, qui peut être lancé en sidecar d’une application. nsqd prend en charge beaucoup de la complexité des protocoles de queue (approche « smart broker/dumb consumer », pour « messager complexe, receveur simple »)  : les clients n’ont qu’à se connecter à l’instance via l’API HTTP ou TCP (il y a des librairies pour la plupart des langages) et à envoyer ou recevoir des messages.

Une des autres forces de NSQ réside dans ses designs de décentralisation et de scalabilité. Quand on a besoin de s’étendre sur de nouvelles machines, il suffit de connecter les émetteurs/récepteurs à l’instance nsqd principale… Ou bien, si on veut aller plus loin, de déployer plusieurs instances nsqd et mettre en place des instances de nsqlookupd, un service de registre. Les instances nsqd vont automatiquement s’enregistrer auprès de nsqlookupd, et les clients vont automatiquement découvrir ces instances via nsqlookupd !

NSQ offre un outil d’administration de cluster, nsqadmin, qui utilise aussi nsqlookupd pour trouver automatiquement les instances et afficher leurs statistiques.

Les fonctionnalités, garanties et tradeoffs de NSQ sont bien documentés. Pour le moment, NSQ réponds parfaitement à nos besoins et offre un chemin clair vers une scalabilité horizontale. Sa simplicité de mise en œuvre et d’utilisation client nous donne aussi la liberté de changer de système facilement dans le futur, si le besoin s’en fait sentir.