Pipelining
Тема дорожной карты · Redis
Пайплайнинг Redis — это клиентская техника, группирующая несколько команд в один сетевой круговой обход и устраняющая задержку цикла «запрос — ответ» на каждую команду. Без пайплайнинга каждый вызов SET, GET или HSET требует полного времени кругового обхода (RTT) до отправки следующей команды; с пайплайнингом сотни команд буферизуются на стороне клиента и отправляются вместе. Клиентские библиотеки предоставляют пайплайнинг через менеджеры контекста или явные объекты пайплайна — например, pipe = r.pipeline() в redis-py с последующим pipe.execute() для сброса всех буферизованных команд. В отличие от транзакций MULTI/EXEC, пайплайнинг не гарантирует атомарности, поэтому команды других клиентов могут выполняться между командами в пайплайне. Пайплайнинг наиболее эффективен при массовой загрузке данных, прогреве кэша и пакетном обновлении метрик, где команды независимы и порядок выполнения между клиентами не имеет значения.
Как это работает
Pipelining батчит несколько команд в один round trip. Без pipelining N команд = N RTT (network latency доминирует для маленьких команд). С pipelining клиент шлёт все N команд, потом читает все N ответов — один RTT на батч. У большинства клиентов есть pipeline() / multi(). Порядок сохраняется; команды всё равно исполняются по очереди на сервере (без атомарности — для неё MULTI/EXEC).
Когда применять
Pipelining — когда есть известный батч независимых команд (bulk insert, multi-get, fan-out write). Прирост throughput в 5-50× типичен для маленьких команд через сеть 1ms. Комбинируйте с MULTI/EXEC для "атомарно + батч". Не пайплайните огромные батчи без flush — память растёт на клиенте.
Типичные ошибки
Ловушки Pipelining: pipelining 1M команд без периодического flush (RAM клиента взрывается); путаница pipelining с транзакциями (без атомарности — конкурентные команды с другого соединения могут вклиниться); error handling, съедающий ошибки в середине pipeline (нужно проверять каждый ответ).