Node.js, (Hi) Redis et la commande multiple

Je joue avec node.js et redis et ai installé la bibliothèque hiredis via cette commande

npm install hiredis redis 

J’ai regardé les multiples exemples ici:

https://github.com/mranney/node_redis/blob/master/examples/multi2.js

A la ligne 17, il est écrit

 // you can re-run the same transaction if you like 

ce qui implique que l’object interne multi.queue n’est jamais effacé une fois l’exécution des commandes terminée.

Ma question est la suivante: comment géreriez-vous la situation dans un environnement http? Par exemple, suivre le dernier utilisateur connecté (cela n’a pas vraiment besoin de multi car il n’exécute qu’une seule commande, mais il est facile à suivre)

 var http = require('http'); redis = require('redis'); client = redis.createClient() multi = client.multi(); http.createServer(function (request, response) { multi.set('lastconnected', request.ip); // won't work, just an example multi.exec(function(err, replies) { console.log(replies); }); }); 

Dans ce cas, multi.exec exécuterait 1 transaction pour le premier utilisateur connecté et 100 transactions pour le 100e utilisateur (car l’object interne multi.queue n’est jamais effacé).

Option 1: devrais-je créer le multi-object dans la fonction de rappel http.createServer, ce qui le tuerait efficacement à la fin de l’exécution de la fonction? Combien coûterait en termes de cycles de processeur la création et la destruction de cet object?

Option 2: L’autre option consisterait à créer une nouvelle version de multi.exec (), similaire à multi.execAndClear (), qui effacera la file d’attente dès que la commande sera exécutée.

Quelle option prendriez-vous? Je suppose que l’option 1 est préférable: nous détruisons un object au lieu de choisir certaines parties de celui-ci. Je veux simplement être sûr que je suis tout nouveau en matière de nœud et de javascript.

Les objects multiples dans node_redis sont très peu coûteux à créer. En tant qu’effet secondaire, j’ai pensé qu’il serait amusant de vous laisser les réutiliser, mais cela n’est évidemment utile que dans certaines circonstances. Allez-y et créez un nouvel object multiple chaque fois que vous avez besoin d’une nouvelle transaction.

Une chose à garder à l’esprit est que vous ne devriez utiliser multi que si vous avez réellement besoin de l’exécution atomique de toutes les opérations sur le serveur Redis. Si vous souhaitez simplement regrouper efficacement une série de commandes pour économiser la bande passante du réseau et réduire le nombre de rappels à gérer, il vous suffit d’envoyer les commandes les unes après les autres. node_redis “pipeline” automatiquement ces demandes au serveur dans l’ordre, et les rappels de commande individuels, le cas échéant, seront appelés dans l’ordre.