Jeśli chodzi o blokowanie poleceń, takich jak BLPOP lub słuchanie kanału Pub/Sub, potrzebujesz asynchronicznego klienta, takiego jak tornado-redis. Możesz zacząć od tego demo, aby zobaczyć, jak klient tornado-redis może zostać wykorzystany do stworzenia prostej aplikacji do publicznego czatu.
Ale w większości innych przypadków polecam używanie synchronicznego klienta redis-py w połączeniu z Hiredis.
Główną zaletą klienta asynchronicznego jest to, że serwer może obsługiwać przychodzące żądania podczas oczekiwania na odpowiedź serwera Redis. Jednak serwer Redis jest tak szybki, że w większości przypadków obciążenie związane z konfiguracją asynchronicznych wywołań zwrotnych w aplikacji Tornado zwiększa całkowity czas przetwarzania żądania niż czas oczekiwania na odpowiedź serwera Redis.
Korzystając z klienta asynchronicznego możesz próbować wysłać wiele żądań do serwera Redis w tym samym czasie, ale serwer Redis jest serwerem jednowątkowym (tak jak serwer Tornado), więc będzie odpowiadał na te żądania jeden po drugim i prawie nic nie zyskasz. W rzeczywistości nie musisz wysyłać wielu poleceń Redis jednocześnie do tego samego serwera Redis, o ile istnieją potoki i polecenia, takie jak MGET/MSET.
Klient asynchroniczny ma pewne zalety, gdy używasz kilku instancji serwera Redis, ale sugeruję używanie klienta synchronicznego (redis-py) i serwera proxy, takiego jak twemproxy lub ten (ten ostatni obsługuje potokowanie i polecenia MGET/MSET).
Proponuję również nie używać puli połączeń podczas korzystania z klienta redis-py w aplikacjach Tornado . Po prostu utwórz jeden Redis instancja obiektu dla każdej bazy danych Redis, z którą łączy się Twoja aplikacja.
