Cuando se trata de bloquear comandos como BLPOP o escuchar un canal Pub/Sub, necesitará un cliente asíncrono como tornado-redis. Puede comenzar con esta demostración para ver cómo se puede usar el cliente tornado-redis para desarrollar una aplicación de chat público simple.
Pero recomendaría usar el cliente redis-py síncrono junto con namedis para la mayoría de los demás casos.
La principal ventaja del cliente asíncrono es que su servidor puede manejar las solicitudes entrantes mientras espera la respuesta del servidor Redis. Sin embargo, el servidor de Redis es tan rápido que, en la mayoría de los casos, la sobrecarga de configurar devoluciones de llamadas asincrónicas en su aplicación Tornado agrega más al tiempo total de procesamiento de solicitudes que al tiempo que se tarda en esperar la respuesta del servidor de Redis.
Con un cliente asíncrono, puede intentar enviar varias solicitudes al servidor de Redis al mismo tiempo, pero el servidor de Redis es de un solo subproceso (al igual que el servidor Tornado), por lo que responderá a estas solicitudes una por una y no ganarás casi nada. Y, de hecho, no tiene que enviar varios comandos de Redis al mismo tiempo al mismo servidor de Redis, siempre que haya canalizaciones y comandos como MGET/MSET.
Un cliente asíncrono tiene algunas ventajas cuando usa varias instancias de servidor Redis, pero sugiero usar un cliente síncrono (redis-py) y un proxy como twemproxy o este (este último admite la canalización y los comandos MGET/MSET).
También sugiero no usar la agrupación de conexiones cuando se usa el cliente redis-py en aplicaciones Tornado . Simplemente cree un solo Redis instancia de objeto para cada base de datos de Redis a la que se conecta su aplicación.
