Ist mein Anwendungsfall für Redis geeignet?

Question

Ich schreibe eine Web-App, die im Grunde Facebook-Events ist, aber mehr improvisiert und in Echtzeit. Ein Benutzer kann ein Ereignis erstellen, und andere Online-Benutzer in dem Bereich (30-Meilen-Radius) sollten das Ereignis sofort sehen. Benutzer können sich für Ereignisse anmelden, und der Gastgeber sollte die Einladungen sehen. Der Gastgeber kann die Veranstaltung absagen und alle Teilnehmer sollten benachrichtigt werden. Kein langes Polling oder Auffrischen ist notwendig, und ich werde wahrscheinlich Webstöcke (socket.io) verwenden

Dieses Konzept ist einfach zu beschreiben, aber ich habe Kopfschmerzen bekommen, nur darüber nachzudenken, wie genau das umgesetzt werden kann. Vor allem, wenn ein Benutzer mehrere Sitzungen hat.

Redis hat meine Aufmerksamkeit vor kurzem erfasst. Kann ich Vorschläge zu meinem Implementierungsplan erhalten, um sicherzugehen, dass ich keinen verrückten Weg gehe?

1. Ich verfolge die Standorte von eingeloggten Benutzern in Redis.
2. Benutzer erstellt Ereignis und ich speichere es in Redis.
3. Ich finde alle Benutzer, die im Umkreis von 30 Meilen von Ereignis sind, und benachrichtigen sie durch socket.io
4. Der Host und die Benutzer, die sich für Ereignis anmelden, werden in Redis pub/sub für jede Art von Benachrichtigungen eingegeben.
5. Sobald Veranstaltung ist vorbei, i-Ereignis von Redis und speichern in MySQL entfernen

Ist meine Implementierung machbar? Macht es Sinn, Redis hier zu verwenden?

Answer 1

Ist meine Implementierung möglich? Macht es Sinn, Redis hier zu verwenden?

Ja. Und ja. Aber der Teufel steckt im Detail.

Es wird nicht so einfach sein, die Nachrichten für Benutzer in einem bestimmten Radius zu verteilen, es sei denn, Sie tun etwas clever hier.

Zum Beispiel könnten Sie Ihre Welt in einige Sektoren teilen, jede mit einem eigenen Pub/Sub-Kanal. Die optimale Größe dieser Sektoren muss durch sorgfältige Experimente, Benchmarking und Profiling ermittelt werden. Jeder Benutzer kann jedoch 9 Kanäle für seinen eigenen Sektor und alle Nachbarsektoren abonnieren, alle Nachrichten erhalten, die aus diesen Sektoren stammen, und die genauen Koordinaten in den Nachrichten prüfen, um zu entscheiden, ob er sich in dem Radius befindet oder nicht.

Es ist einfacher als auf alle Nachrichten zu hören und sicherlich einfacher als der Server die Nachrichten zu versenden, um Benutzer im Radius zu korrigieren.

Mit diesem Ansatz könnte der Server keine Ahnung haben, was jeder Sektor sogar bedeutet, es hätte nur eine Anzahl von Kanälen und eine Anzahl von Abonnenten, um die Nachrichten zu übergeben, aber die Clients müssten nicht nur alles hören zu jenen Kanälen, die Nachrichten enthalten können, die eine Chance haben, im Radius zu sein.

Mit dieser Idee könnten Sie sogar verschiedene Server verschiedene Sektoren behandeln, weil diese Server nicht voneinander wissen müssen. Nur die Clients müssen die Server/Sektoren abonnieren, die möglicherweise einige für sie relevante Nachrichten haben könnten.

Es mag wie eine vorzeitige Optimierung erscheinen, über solche Dinge in solch einem frühen Stadium nachzudenken, aber wenn Sie erheblichen Verkehr in Ihrem System bekommen, können Sie sicher sein, dass es schwierig wird, die Nachrichten zu routen, ohne an einen Weg zu denken um es effizient zu machen.

Jetzt, ob Redis dafür zu verwenden ist oder nicht, ist eine andere Frage. Wenn Ihre Daten trotzdem über Socket.io oder WebSocket übertragen werden, kann alles nur vom Server erledigt werden. Wenn Sie nicht mehrere Server pro Kanal/Sektor benötigen, müssen Sie Redis überhaupt nicht verwenden. Wenn Sie jedoch mehrere Instanzen Ihres Back-End-Dienstes benötigen, mit denen das Front-End eine Verbindung herstellt und diese Instanzen die Nachrichten zwischen ihnen und nicht nur zwischen den Clients weitergeben müssen, benötigen Sie möglicherweise Redis oder ein anderes Pub/Sub-System.

Es hängt wirklich davon ab, wie es skalieren wird. Aber ich würde Redis hier sicherlich berücksichtigen.