Quand il s'agit de bloquer des commandes comme BLPOP ou d'écouter un canal Pub/Sub, vous aurez besoin d'un client asynchrone comme tornado-redis. Vous pouvez commencer par cette démo pour voir comment le client tornado-redis peut être utilisé pour développer une simple application de chat public.
Mais je recommanderais d'utiliser le client redis-py synchrone en conjonction avec leaseis dans la plupart des autres cas.
Le principal avantage du client asynchrone est que votre serveur peut gérer les demandes entrantes en attendant la réponse du serveur Redis. Cependant, le serveur Redis est si rapide que, dans la plupart des cas, une surcharge liée à la configuration de rappels asynchrones dans votre application Tornado ajoute plus au temps total de traitement de la demande qu'au temps passé à attendre la réponse du serveur Redis.
En utilisant un client asynchrone, vous pouvez essayer d'envoyer plusieurs requêtes au serveur Redis en même temps, mais le serveur Redis est un serveur à thread unique (tout comme le serveur Tornado), il répondra donc à ces requêtes une par une et vous ne gagnerez presque rien. Et, en fait, vous n'avez pas besoin d'envoyer plusieurs commandes Redis en même temps au même serveur Redis tant qu'il existe des pipelines et des commandes comme MGET/MSET.
Un client asynchrone présente certains avantages lorsque vous utilisez plusieurs instances de serveur Redis, mais je suggère d'utiliser un client synchrone (redis-py) et un proxy comme twemproxy ou celui-ci (ce dernier prend en charge le pipelining et les commandes MGET/MSET).
Je suggère également de ne pas utiliser le regroupement de connexions lors de l'utilisation du client redis-py dans les applications Tornado . Créez simplement un seul Redis instance d'objet pour chaque base de données Redis à laquelle votre application se connecte.
