Architectonisch gezien zijn beide keuzes hetzelfde als het opslaan van gegevens in een Oracle-databaseserver zodat een andere toepassing kan worden opgehaald.
Zowel de RabbitMQ- als de Redis-oplossing vereisen dat uw apps verbinding maken met een intermediaire server die de datacommunicatie afhandelt. Redis lijkt het meest op Oracle, omdat het eenvoudig kan worden gebruikt als een permanente database met een netwerk-API. Maar RabbitMQ is een beetje anders omdat de MQ-makelaar niet echt verantwoordelijk is voor het aanhouden van gegevens. Als je het goed configureert en de juiste opties gebruikt bij het publiceren van een bericht, dan zal RabbitMQ de gegevens daadwerkelijk voor je bewaren, maar je kunt de gegevens er alleen uit krijgen als onderdeel van het normale proces voor het in de wachtrij plaatsen van berichten. Met andere woorden, RabbitMQ is bedoeld voor het communiceren van berichten en biedt alleen persistentie als een manier om te herstellen van netwerkproblemen of systeemcrashes.
Ik zou willen voorstellen om RabbitMQ te gebruiken en welke programmeertalen je al kent. Aangezien de M in LAMP meestal wordt geïnterpreteerd als MySQL, betekent dit dat u MySQL helemaal niet zou gebruiken, of het alleen zou gebruiken voor langdurige opslag van gegevens, niet voor realtime communicatie.
De RabbitMQ-site heeft een enorme hoeveelheid documentatie over het bouwen van apps met AMQP. Ik stel voor dat je, nadat je RabbitMQ hebt geïnstalleerd, de documenten voor rabbitmqctl doorleest. en maak vervolgens een vhost om in te experimenteren. Op die manier is het gemakkelijk om je experimenten op te schonen zonder alles opnieuw in te stellen. Ik raad ook aan om alleen topic-uitwisselingen te gebruiken, omdat je het gedrag van directe en fanout-uitwisselingen kunt emuleren door jokertekens in de routing_key te gebruiken. Onthoud dat je alleen berichten publiceert naar uitwisselingen en je alleen berichten ontvangt van wachtrijen. De uitwisseling is verantwoordelijk voor het matchen van de routing_key van het bericht met de binding_key van de wachtrij om te bepalen welke wachtrijen een kopie van het bericht moeten ontvangen. Het is de moeite waard om het hele AMQP-model te leren, zelfs als u alleen van plan bent om berichten naar één wachtrij te sturen met dezelfde naam als de routing_key.
Als u uw client in de browser bouwt en u wilt een prototype bouwen, dan zou u moeten overwegen om vandaag XHR te gebruiken en vervolgens over te stappen op iets als Kamaloka-js, een pure Javascript-implementatie van AMQP (het AMQ-protocol) dat is het standaard protocol dat wordt gebruikt om te communiceren met een RabbitMQ message broker. Met andere woorden, bouw het op met wat je vandaag weet, en versnel het later met iets (AMQP) dat een lange termijn toekomst heeft in je gereedschapskist.