D'un point de vue architectural, vos deux choix sont les mêmes que le stockage de données dans un serveur de base de données Oracle pour qu'une autre application les récupère.
Les solutions RabbitMQ et Redis nécessitent toutes deux que vos applications se connectent à un serveur intermédiaire qui gère les communications de données. Redis ressemble le plus à Oracle, car il peut être utilisé simplement comme une base de données persistante avec une API réseau. Mais RabbitMQ est un peu différent car le MQ Broker n'est pas vraiment responsable de la persistance des données. Si vous le configurez correctement et utilisez les bonnes options lors de la publication d'un message, alors RabbitMQ conservera les données pour vous, mais vous ne pourrez pas les extraire, sauf dans le cadre du processus normal de mise en file d'attente des messages. En d'autres termes, RabbitMQ est destiné à la communication de messages et n'offre la persistance que comme moyen de récupérer des problèmes de réseau ou des pannes du système.
Je suggérerais d'utiliser RabbitMQ et tous les langages de programmation que vous connaissez déjà. Étant donné que le M dans LAMP est généralement interprété comme MySQL, cela signifie que vous n'utiliserez pas MySQL du tout, ou que vous ne l'utiliserez que pour le stockage à long terme des données, pas pour les communications en temps réel.
Le site RabbitMQ contient une énorme quantité de documentation sur la création d'applications avec AMQP. Je suggère qu'après avoir installé RabbitMQ, vous lisiez la documentation pour rabbitmqctl puis créez un vhost pour expérimenter. De cette façon, il est facile de nettoyer vos expériences sans tout réinitialiser. Je suggère également d'utiliser uniquement les échanges de sujets, car vous pouvez émuler le comportement des échanges directs et de déploiement en utilisant des caractères génériques dans le routing_key. Rappelez-vous, vous ne publiez que des messages sur des échanges et vous ne recevez que des messages provenant de files d'attente. L'échange est responsable de la correspondance de modèle entre la clé de routage du message et la clé de liaison de la file d'attente pour déterminer quelles files d'attente doivent recevoir une copie du message. Il vaut la peine d'apprendre l'ensemble du modèle AMQP même si vous ne prévoyez d'envoyer des messages qu'à une seule file d'attente portant le même nom que le routing_key.
Si vous créez votre client dans le navigateur et que vous souhaitez créer un prototype, vous devriez envisager d'utiliser XHR aujourd'hui, puis passer à quelque chose comme Kamaloka-js qui est une implémentation Javascript pure d'AMQP (le protocole AMQ) qui est le protocole standard utilisé pour communiquer avec un courtier de messages RabbitMQ. En d'autres termes, construisez-le avec ce que vous savez aujourd'hui, puis accélérez-le plus tard avec quelque chose (AMQP) qui a un avenir à long terme dans votre boîte à outils.
