SCAN итерация
Тема дорожной карты · Redis
SCAN — курсорный итератор Redis для безопасного перебора ключей в in-memory хранилище без блокировки сервера, в отличие от устаревшей команды KEYS. Каждый вызов SCAN cursor [MATCH pattern] [COUNT hint] возвращает новый курсор и частичный набор совпадающих ключей; итерация продолжается вызовами SCAN с возвращённым курсором до тех пор, пока он не вернёт 0, сигнализируя о полном обходе пространства ключей. Параметр COUNT является подсказкой Redis о количестве возвращаемых элементов за вызов, однако реальный размер пакета варьируется — это не жёсткое ограничение, и Redis может вернуть больше или меньше ключей в зависимости от плотности внутренней хэш-таблицы. SCAN не блокирует сервер и безопасен для продакшна: каждый вызов амортизированно занимает O(1) времени, что делает его правильным инструментом для перечисления ключей кэша, отладки или пакетного удаления по истечении срока в крупных Redis-развёртываниях. Варианты HSCAN, SSCAN и ZSCAN предоставляют такой же курсорный подход для итерации по полям хэша, участникам множества и участникам отсортированного множества соответственно в рамках одного ключа Redis.
Как это работает
SCAN итерация батчит несколько команд в один 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 — память растёт на клиенте.
Типичные ошибки
Ловушки SCAN итерация: pipelining 1M команд без периодического flush (RAM клиента взрывается); путаница pipelining с транзакциями (без атомарности — конкурентные команды с другого соединения могут вклиниться); error handling, съедающий ошибки в середине pipeline (нужно проверять каждый ответ).