Von der Architektur her entsprechen beide Ihrer Entscheidungen dem Speichern von Daten auf einem Oracle-Datenbankserver, damit eine andere Anwendung sie abrufen kann.
Sowohl die RabbitMQ- als auch die Redis-Lösung erfordern, dass Ihre Apps eine Verbindung zu einem zwischengeschalteten Server herstellen, der die Datenkommunikation abwickelt. Redis ist Oracle am ähnlichsten, da es einfach als persistente Datenbank mit einer Netzwerk-API verwendet werden kann. Aber RabbitMQ ist ein wenig anders, da der MQ Broker nicht wirklich für die Persistenz von Daten verantwortlich ist. Wenn Sie es richtig konfigurieren und beim Veröffentlichen einer Nachricht die richtigen Optionen verwenden, speichert RabbitMQ die Daten tatsächlich für Sie, aber Sie können die Daten nur als Teil des normalen Nachrichtenwarteschlangenprozesses abrufen. Mit anderen Worten, RabbitMQ dient zum Übermitteln von Nachrichten und bietet nur Persistenz als Möglichkeit zur Wiederherstellung nach Netzwerkproblemen oder Systemabstürzen.
Ich würde vorschlagen, RabbitMQ und alle Programmiersprachen zu verwenden, mit denen Sie bereits vertraut sind. Da das M in LAMP normalerweise als MySQL interpretiert wird, bedeutet dies, dass Sie MySQL entweder gar nicht oder nur für die Langzeitspeicherung von Daten verwenden würden, nicht für die Echtzeitkommunikation.
Die RabbitMQ-Site enthält eine riesige Menge an Dokumentation zum Erstellen von Apps mit AMQP. Ich schlage vor, dass Sie nach der Installation von RabbitMQ die Dokumentation für rabbitmqctl durchlesen und erstellen Sie dann einen vhost zum Experimentieren. Auf diese Weise ist es einfach, Ihre Experimente zu bereinigen, ohne alles zurücksetzen zu müssen. Ich schlage auch vor, nur Themenaustausch zu verwenden, da Sie das Verhalten von direkten und Fanout-Austauschen emulieren können, indem Sie Platzhalter im routing_key verwenden. Denken Sie daran, dass Sie Nachrichten nur an Austauschen veröffentlichen und nur Nachrichten aus Warteschlangen erhalten. Die Vermittlungsstelle ist für den Musterabgleich des routing_key der Nachricht mit dem binding_key der Warteschlange verantwortlich, um zu bestimmen, welche Warteschlangen eine Kopie der Nachricht erhalten sollen. Es lohnt sich, das gesamte AMQP-Modell zu lernen, auch wenn Sie nur vorhaben, Nachrichten an eine Warteschlange mit dem gleichen Namen wie der routing_key zu senden.
Wenn Sie Ihren Client im Browser erstellen und einen Prototyp erstellen möchten, sollten Sie heute nur XHR verwenden und dann zu etwas wie Kamaloka-js wechseln, das eine reine Javascript-Implementierung von AMQP (dem AMQ-Protokoll) ist ist das Standardprotokoll, das für die Kommunikation mit einem RabbitMQ-Nachrichtenbroker verwendet wird. Mit anderen Worten, bauen Sie es mit dem auf, was Sie heute wissen, und beschleunigen Sie es später mit etwas (AMQP), das eine langfristige Zukunft in Ihrer Toolbox hat.
