men jeg forstår ikke, hvordan brugen af RedisStore i den kode ville være anderledes end at bruge MemoryStore. Kan nogen forklare mig det?
Forskellen er, at når du bruger standard MemoryStore , vil enhver besked, som du udsender i en arbejder, kun blive sendt til klienter, der er tilsluttet den samme arbejder, da der ikke er nogen IPC mellem arbejderne. Brug af RedisStore , vil din besked blive offentliggjort på en redis-server, som alle dine medarbejdere abonnerer på. Således vil beskeden blive opfanget og udsendt af alle arbejdere og alle tilsluttede klienter.
Og hvad er forskellen mellem at konfigurere socket.io til at bruge redisstore i forhold til at oprette din egen redis-klient og indstille/hente dine egne data?
Jeg er ikke indgående bekendt med RedisStore , og så jeg er ikke sikker på alle forskelle. Men at gøre det selv ville være en helt gyldig praksis. I så fald kan du udgive alle beskeder til en redis-server og lytte til dem i din socket-handler. Det ville nok være mere arbejde for dig, men du ville også have mere kontrol over, hvordan du vil sætte det op. Jeg har selv gjort noget lignende:
// Publishing a message somewhere
var pub = redis.createClient();
pub.publish("messages", JSON.stringify({type: "foo", content: "bar"}));
// Socket handler
io.sockets.on("connection", function(socket) {
var sub = redis.createClient();
sub.subscribe("messages");
sub.on("message", function(channel, message) {
socket.send(message);
});
socket.on("disconnect", function() {
sub.unsubscribe("messages");
sub.quit();
});
});
Det betyder også, at du selv skal sørge for mere avanceret besked-routing, for eksempel ved at publicere/abonnere på forskellige kanaler. Med RedisStore , får du den funktionalitet gratis ved at bruge socket.io-kanaler (io.sockets.of("channel").emit(...) ).
En potentielt stor ulempe ved dette er, at socket.io-sessioner ikke deles mellem arbejdere. Dette vil sandsynligvis betyde problemer, hvis du bruger nogen af de lange afstemningstransporter.