dans Redis Documentation de protocole Il étage:
Un client peut utiliser la même connexion pour délivrer plusieurs commandes. La pipeline est prise en charge afin que plusieurs commandes puissent être envoyées. avec une seule opération d'écriture par le client, il n'est pas nécessaire de lire La réponse du serveur afin de délivrer la commande suivante. Toutes les réponses peut être lu à la fin.
Cependant, je ne trouve aucun exemple de la manière dont cela est réellement mis en œuvre. Comment un client de Redis implique-t-il la pipeline?
3 Réponses :
Tant que vous pouvez facilement délimiter des messages sur un flux TCP, peu de support est vraiment nécessaire pour qu'un serveur supporte la pipelining, la pile TCP tamponnera les données pour vous et, en tant que serveur, vous pouvez simplement lire / analyser les demandes -by-one et envoyer des réponses en arrière lorsque vous terminez les demandes. Le client / serveur doit simplement être conscient et gérer les cas lorsque ces tampons se remplissent, ce qui n'est pas une impasse.
Cela dit, pour ReDIS Jetez un coup d'œil à ProcessInputBuffer () / ProcessMultiBulkbuffer () dans Networking.c, Redis a également sa propre mise en mémoire tampon de sortie, voir E.G. addreply ()
Quelques bons, des exemples simples de la manière dont il est implémenté peut être trouvé dans la source du client Ruby Redis, REDIS-RB , et l'un des Python, Redis-py , respectivement énumérés ci-dessous.
Ils font essentiellement ce que Taylorotwell mentionné ci-dessus, concaténate côté client les demandes qui seront apportées à ReDIS dans un pipeline dans une seule demande de réseau, tandis que les transactions utiliseraient les commandes de Redis redis-rb (de REDIS.RB et pipeline.rb ): Un autre bon exemple peut être trouvé dans la source pour < un href = "https://github.com/andymcCurdy/redis-py/blob/74d4666A 4190541EE11DA3EC629A60B9B1CE6D9D / REDIS / Client.py "rel =" NOREFERRER "> ReDIS-PY , un client de Redis Python. Espère que cela aide. Multi / EXEC pour commencer et mettre fin à une transaction.
Je viens de jeter quelques idées aux réponses ci-dessus. Une façon de comprendre Redis Pipeline est de comprendre le fait que Redis Pipeline est complètement une implémentation côté client et le serveur ReDIS n'a rien à voir avec cela. Bien que cela diffère parmi la mise en œuvre de la clientèle différente, voici l'idée généralisée:
La pipeline vise à résoudre les problèmes de latence de réponse dans des environnements de latence de réseau élevés. Donc, moins le temps passé sur le réseau dans l'envoi de commandes et de la lecture de la réponse, mieux c'est. Ceci est effectivement réalisé en tampon. Le client peut (ou peut ne pas) tamponner les commandes de la pile TCP (comme mentionné dans d'autres réponses) avant qu'elles ne soient envoyées sur le serveur. Une fois qu'ils sont envoyés sur le serveur, le serveur les exécute et les tampons sur le côté serveur. Contrairement au cas habituel où le client lit la réponse dès que la réponse est reçue, dans le cas de la pipeline, le client lit les réponses formant la mémoire tampon côté serveur dans des pièces ou lorsque l'application exécute «Sync» (Fermer le pipeline). Ceci est avantageux car le temps passé sur le réseau par le client en lecture des réponses est beaucoup moins petit.
Voici un article sur mon blog que vous pouvez faire référence à avoir une meilleure idée: http://nachivpn.blogspot.in/2014/11/redis-pipeline -Expliné.html