Pour la persistance des objets, j'ai ajouté Redissupport en utilisant node_redis. Ensuite, j'ai remplacé la boucle client.send sur le tableau de canaux par Redis pub/sous une couche d'abstraction. Mais j'ai remarqué que je devais créer un nouveau client Redis pour chaque utilisateur ayant souscrit un abonnement. Et j'avais encore besoin de stocker les informations du client socket.io pour envoyer des messages lors de la publication. À quel point est-ce évolutif ? Existe-t-il d'autres implémentations (meilleures) ou d'autres optimisations que je pourrais faire ? Que feriez-vous ?
Oui, vous devez créer un nouveau client Redis pour chaque requête io. Il est lourd et non évolutif. Mais la création d'une nouvelle connexion client Redis ne consomme pas beaucoup de mémoire. Donc, si le nombre d'utilisateurs de votre système n'est pas supérieur à 5000, tout va bien. Pour évoluer, vous pouvez ajouter un serveur redis esclave pour résoudre la publication et l'abonnement lourds et si vous êtes préoccupé par la création d'un grand nombre de connexions, vous pouvez augmenter votre système d'exploitation uLIMIT.
Vous n'avez pas besoin de stocker le client socket.io dans le message envoyé. Une fois redis reçu le message de canal abonné. Il enverra un message à un client io particulier.
subscribe.on("message",function(channel,message) {
var msg = { message: [client.sessionId, message] };
buffer.push(msg);
if (buffer.length 15) buffer.shift();
client.send(msg); > });
Pour s'abonner multicanal. Je vous suggère de pré-stocker tous les utilisateurs avec plus d'un canal (vous pouvez utiliser le stockage Mongodb ou redis).
var store = redis.createClient();
var subscriber= redis.createClient()
store.hgetall(UID, function(e, obj){
subscriber.subscribe(obj.ChannelArray.toArray());
})
