Wenn Sie socket.io/node.js und redis pub / sub zusammenführen, um ein Echtzeit-Web-Broadcast-System zu erstellen, das von Serverereignissen gesteuert wird und mehrere Transporte verarbeiten kann, gibt es anscheinend drei Ansätze:

'createClient' stellt eine Verbindung wieder her und abonniert Channel (s). Schließen Sie den Client bei einer Socket.io-Clientverbindung an einen Socket.io-Raum an. Rufen Sie im Ereignis redis.on ("message", ...) io.sockets.in (room) .emit ("event", data) auf, um es an alle Clients im entsprechenden Raum zu verteilen. MögenWie kann ich meine Verbindung in socket.io wiederverwenden?

Mit 'createClient' wird die Verbindung wiederhergestellt. Schließen Sie den Client bei einer Socket.io-Client-Verbindung an einen Socket.io-Raum an und abonnieren Sie die entsprechenden Redis-Kanäle. Fügen Sie redis.on ("message", ...) in den Client-Verbindungsabbau ein und rufen Sie bei Erhalt der Nachricht client.emit ("event", data) auf, um das Ereignis auf dem bestimmten Client auszulösen. Wie die Antwort inBeispiele für die Verwendung von RedisStore in socket.io

Verwenden Sie den in socket.io gebackenen RedisStore, und senden Sie ihn vom einzelnen "Dispatch" -Kanal in Redis nach dem Socketio-Spec-Protokoll.

Nummer 1 ermöglicht die einmalige Behandlung des Redis-Unterereignisses und des zugeordneten Ereignisses für alle Clients. Nummer 2 bietet einen direkteren Einstieg in Redis Pub / Sub. Nummer 3 ist einfacher, bietet jedoch wenig Kontrolle über die Nachrichtenereignisse.

In meinen Tests weisen jedoch alle eine unerwartet niedrige Leistung mit mehr als einem verbundenen Client auf. Bei den fraglichen Serverereignissen handelt es sich um 1.000 Nachrichten, die so schnell wie möglich auf einem Redis-Kanal veröffentlicht und so schnell wie möglich verteilt werden. Die Leistung wird anhand der Timings auf den verbundenen Clients gemessen (socket.io-client-basiert, die Zeitstempel zur Analyse in einer Redis-Liste protokollieren).

Ich vermute, dass der Server in Option 1 die Nachricht empfängt und sie dann nacheinander an alle verbundenen Clients schreibt. In Option 2 empfängt der Server jede Nachricht mehrmals (einmal pro Client-Abonnement) und schreibt sie an den entsprechenden Client. In beiden Fällen erreicht der Server das zweite Nachrichtenereignis erst, wenn es allen verbundenen Clients mitgeteilt wurde. Eine Situation, die sich mit steigender Parallelität deutlich verschärft.

Dies scheint im Widerspruch zu der wahrgenommenen Weisheit der Stapelfähigkeiten zu stehen. Ich möchte glauben, aber ich kämpfe.

Ist dieses Szenario (Verteilung mit geringer Latenz und hohem Nachrichtenaufkommen) mit diesen Tools (noch) nicht möglich, oder fehlt mir ein Trick?