Existe-t-il une bibliothèque redis bloquante pour node.js?

Redis est très rapide. Pour la plupart sur ma machine, il est aussi rapide que des instructions Javascript natives ou des appels de fonctions dans node.js. Il est facile/indolore d'écrire du code Javascript régulier dans node.js car aucun callback n'est nécessaire. Je ne vois pas pourquoi il ne devrait pas être aussi simple d'obtenir/de définir des données de clé/valeur dans Redis en utilisant node.js.Existe-t-il une bibliothèque redis bloquante pour node.js?

En supposant que node.js et Redis sont sur la même machine, existe-t-il des bibliothèques npm qui permettent d'interagir avec Redis sur node.js en utilisant des appels bloquants? Je sais que cela doit être une bibliothèque C/C++ interfaçant avec V8.

Source

2011-05-23 rafidude

Vous ne voulez pas bloquer les bibliothèques dans le nœud. – Raynos

Pouvez-vous expliquer pourquoi vous souhaitez bloquer les appels sur nodej de manière convaincante et utile? – jcolebrand

Je comprends que les appels bloquants peuvent créer d'énormes goulots d'étranglement. Je peux utiliser des fonctions Javascript natives (ex: expressions régulières etc.) et des boucles d'un blocage qui s'exécutent très rapidement en V8. Si obtenir/configurer des données Redis peut être presque aussi rapide, pourquoi ne puis-je pas utiliser une bibliothèque Redis bloquante qui a des fonctions telles que getSync, hsetSync, etc.? Cela rend l'écriture de code beaucoup plus facile (val = client.getSync (clé); # 1 ligne) au lieu d'utiliser les callbacks (3+ lignes). – rafidude

Je suppose que vous voulez vous assurer que toutes vos opérations d'insertion redis ont été effectuées. Pour ce faire, vous pouvez utiliser les commandes MULTI pour insérer des clés ou effectuer d'autres opérations. Le module https://github.com/mranney/node_redis met en file d'attente les commandes placées dans plusieurs objets et les exécute en conséquence.

De cette façon, vous n'avez besoin que d'un callback, à la fin de l'appel exec.

Source

2011-05-23 23:17:45 Dragunov

Bon compromis! Un seul rappel, un seul multi-bloc qui exécute plusieurs commandes, ensemble, m'aide à éviter les longues spagetti de rappel. – rafidude

Bon ça marche pour vous :). J'ai eu le même problème, et c'est ainsi que je l'ai surmonté: D. Sans parler du gain de performance, et pas de goulots d'étranglement à nouveau. – Dragunov

Non, vous ne voulez pas MULTI, vous voulez juste pipelining, ce qui résout ce problème. – djechlin

Alors que Redis est rapide, il n'est pas instantané ... c'est pourquoi vous devez utiliser un rappel si vous voulez continuer l'exécution en vous assurant que vos valeurs sont là. La seule façon que je pense que vous pourrait (et je ne suggère pas que vous le faites) atteindre cet utiliser un rappel avec une variable qui est le prédicat pour laisser une minuterie.

Source

2011-05-23 15:14:04

Le code de blocage crée un goulot d'étranglement MASSIVE.

Si vous utilisez le code de blocage, votre serveur deviendra INCREDIBLEMENT lent. Rappelez-vous que le nœud est à un seul thread. Ainsi, tout code de blocage bloquera le nœud pour chaque client connecté.

Votre propre analyse comparative montre qu'il est assez rapide pour un client. L'avez-vous comparé avec 1000 clients? Si vous essayez ceci, vous verrez pourquoi le code de blocage est mauvais

Source

2011-05-23 15:14:53 Raynos

qui annulerait évidemment les avantages de node.js. +1 – jcolebrand

Je ne crois pas que l'accès simultané à Redis sur le même serveur que node.js crée un énorme goulot d'étranglement. La plupart de mes opérations get/set sur Redis key/val DB sont rapides comme l'éclair. – rafidude

@ pm8 ils sont rapides comme l'éclair pour un client. Mais que faire si vous le faites pour 1000 en même temps? Goulot d'étranglement massif. – Raynos

Cela ressemble à un piège à ours commun pour les développeurs qui tentent de s'habituer au modèle de programmation événementielle de Node. Qu'est-ce qui se passe est ceci: vous rencontrez une situation où le modèle asynchrone/callback n'est pas un bon ajustement, vous comprenez ce dont vous avez besoin est un moyen de bloquer le code, vous demandez à Google/StackExchange sur le blocage dans Node, et tout ce que vous obtenez est une réprimande sur la façon dont le blocage est.

Ils ont raison de bloquer, ("attendre le résultat de ceci avant de faire quoi que ce soit d'autre"), n'est pas quelque chose que vous devriez essayer de faire dans le nœud. Mais ce que je trouve plus utile, c'est de réaliser que 99,9% du temps, vous n'êtes pas vraiment à la recherche d'un moyen de bloquer, vous cherchez juste un moyen de créer votre application, "attendez le résultat de cette avant de continuer à faire cela ", ce qui n'est pas exactement la même chose. Essayez d'examiner l'idée de "contrôle de flux" dans le nœud plutôt que de "bloquer" pour certains modèles de conception qui pourraient être plus en adéquation avec ce que vous essayez de faire.Voici une liste des bibliothèques à consulter:

https://github.com/joyent/node/wiki/modules#wiki-async-flow

Je suis nouveau nœud aussi, mais je suis vraiment creuser Async: https://github.com/caolan/async

Source

2012-06-23 14:51:45

+1 pour avoir répondu à la bonne question. – djechlin

+1 pour signaler un bon outil utilisable. Je tiens à ajouter que «yield»/générateurs sont juste autour du coin (déjà dans 0.11 instable); sur https://github.com/loveencounterflow/coffy-script, j'essaye de montrer à quel point il est utile d'alléger certains soucis asynchrones. – flow

Vous pouvez pirater le moteur google v8 open source et peut-être ajouter des variables de multithreading et de condition. –

Existe-t-il une bibliothèque redis bloquante pour node.js?

Répondre

Questions connexes