Quando se trata de bloquear comandos como BLPOP ou ouvir um canal Pub/Sub, você precisará de um cliente assíncrono como tornado-redis. Você pode começar com esta demonstração para ver como o cliente tornado-redis pode ser usado para desenvolver um aplicativo de bate-papo público simples.
Mas eu recomendaria usar o cliente redis-py síncrono em conjunto com contratadois para a maioria dos outros casos.
A principal vantagem do cliente assíncrono é que seu servidor pode lidar com solicitações recebidas enquanto aguarda a resposta do servidor Redis. No entanto, o servidor Redis é tão rápido que, na maioria dos casos, uma sobrecarga de configuração de retornos de chamada assíncronos em seu aplicativo Tornado adiciona mais ao tempo total de processamento da solicitação do que o tempo gasto na espera pela resposta do servidor Redis.
Usando um cliente assíncrono, você pode tentar enviar várias solicitações ao servidor Redis ao mesmo tempo, mas o servidor Redis é de thread único (assim como o servidor Tornado), portanto, ele responderá a essas solicitações uma a uma e você não ganhará quase nada. E, na verdade, você não precisa enviar vários comandos Redis ao mesmo tempo para o mesmo servidor Redis, desde que haja pipelines e comandos como MGET/MSET.
Um cliente assíncrono tem algumas vantagens quando você usa várias instâncias de servidor Redis, mas sugiro usar um cliente síncrono (redis-py) e um proxy como twemproxy ou este (o último suporta pipelining e comandos MGET/MSET).
Também sugiro não usar o pool de conexões ao usar o cliente redis-py em aplicativos Tornado . Basta criar um único
Redis
instância de objeto para cada banco de dados Redis ao qual seu aplicativo se conecta.