Arkitektonisk er begge dine valg det samme som at gemme data på en Oracle-databaseserver, så en anden applikation kan hente dem.
Både RabbitMQ og Redis-løsningen kræver, at dine apps opretter forbindelse til en mellemliggende server, der håndterer datakommunikationen. Redis minder mest om Oracle, fordi den simpelthen kan bruges som en vedvarende database med en netværks-API. Men RabbitMQ er lidt anderledes, fordi MQ Broker egentlig ikke er ansvarlig for vedvarende data. Hvis du konfigurerer det rigtigt og bruger de rigtige muligheder, når du udgiver en besked, vil RabbitMQ faktisk bevare dataene for dig, men du kan ikke få dataene ud, undtagen som en del af den normale beskedkøproces. Med andre ord er RabbitMQ til at kommunikere beskeder og tilbyder kun vedholdenhed som en måde at komme sig efter netværksproblemer eller systemnedbrud.
Jeg vil foreslå at bruge RabbitMQ og hvilke programmeringssprog du allerede er bekendt med. Da M i LAMP normalt fortolkes som MySQL, betyder det, at du enten slet ikke ville bruge MySQL eller kun ville bruge det til langtidslagring af data, ikke til realtidskommunikation.
RabbitMQ-siden har en enorm mængde dokumentation om at bygge apps med AMQP. Jeg foreslår, at efter du har installeret RabbitMQ, læser du dokumenterne for rabbitmqctl igennem og opret derefter en vhost at eksperimentere i. På den måde er det nemt at rydde op i dine eksperimenter uden at nulstille alt. Jeg foreslår også, at du kun bruger emneudvekslinger, fordi du kan efterligne adfærden for direkte og fanout-udvekslinger ved at bruge jokertegn i routing_key. Husk, du udgiver kun beskeder til udvekslinger, og du modtager kun beskeder fra køer. Udvekslingen er ansvarlig for, at mønsteret matcher meddelelsens routing_key til køens binding_key for at bestemme, hvilke køer der skal modtage en kopi af meddelelsen. Det er umagen værd at lære hele AMQP-modellen, selvom du kun planlægger at sende beskeder til én kø med samme navn som routing_key.
Hvis du bygger din klient i browseren, og du vil bygge en prototype, så bør du overveje bare at bruge XHR i dag, og derefter flytte til noget som Kamaloka-js, som er en ren Javascript-implementering af AMQP (AMQ-protokollen) som er standardprotokollen, der bruges til at kommunikere til en RabbitMQ-meddelelsesmægler. Med andre ord, byg det med det, du ved i dag, og fremskynd det senere, hvilket noget (AMQP), der har en langsigtet fremtid i din værktøjskasse.