Как найти все ключи по шаблону в Redis

Redis — одна из самых популярных in-memory баз данных, широко используемых для кэширования, хранения сессий, очередей и временных данных. Одной из частых задач при работе с Redis становится поиск ключей по определённому шаблону. Это может быть необходимо при отладке, мониторинге, очистке устаревших данных или анализе структуры хранилища. В отличие от реляционных СУБД, Redis не поддерживает полноценные SQL-подобные запросы, поэтому прямой выбор по маске требует понимания специфики его API и потенциальных ограничений производительности.

Когда использовать KEYS, а когда SCAN?

Команда KEYS — самое простое решение для поиска ключей по шаблону. Она принимает один аргумент — паттерн, например user:*:session, и возвращает список всех совпадающих ключей. Синтаксис шаблона соответствует стандартным правилам glob-подобного сопоставления:

• * — любое количество любых символов;
• ? — ровно один символ;
• [abc] — один символ из указанного набора;
• [a-z] — диапазон символов.

Например:

KEYS user:123:*

вернёт все ключи, начинающиеся с user:123:.
Однако у команды KEYS есть критический недостаток: она полностью сканирует всю ключевую базу и блокирует сервер на время выполнения. В системах с миллионами ключей это может занять секунды, что делает её неприемлемой для использования в рабочих средах.

Альтернатива — команда SCAN. Она работает итеративно, возвращая небольшие порции ключей за один вызов. Это позволяет обходить весь набор ключей без блокировки сервера. SCAN поддерживает параметр MATCH, позволяя фильтровать результаты по шаблону прямо на стороне Redis.

Сравнение KEYS и SCAN

Как эффективно использовать SCAN с MATCH

Команда SCAN использует концепцию курсоров. Вы начинаете с курсора 0 и повторяете вызовы до тех пор, пока он снова не вернёт 0, что означает завершение обхода.
Формат команды:

SCAN cursor [MATCH pattern] [COUNT count]

• cursor — текущая позиция в обходе (возвращается предыдущим вызовом);
• MATCH pattern — необязательный шаблон для фильтрации;
• COUNT count — примерное количество элементов, которые следует вернуть за одну итерацию (не гарантируется).

Пример использования в CLI:

SCAN 0 MATCH session:* COUNT 100

Первый вызов возвращает что-то вроде:

1) "456"
2) 1) "session:abc"
 2) "session:def"

Где 456 — следующий курсор. Затем нужно вызвать:

SCAN 456 MATCH session:* COUNT 100

И так до тех пор, пока курсор не станет равен 0.

Реализация на Python с использованием redis-py

Библиотека redis-py предоставляет удобный метод scan_iter(), который автоматизирует итерации:

import redis
r = redis.Redis(host='localhost', port=6379, db=0)
pattern = 'user:*:settings'
for key in r.scan_iter(match=pattern, count=100):
 print(key.decode('utf-8'))

Этот код безопасно перебирает все ключи по шаблону, не блокируя ни клиент, ни сервер.

Обработка ошибок и таймауты

При длительном сканировании возможны сетевые разрывы или таймауты. Рекомендуется реализовать механизм восстановления:

• Сохраняйте текущий курсор в лог или временное хранилище;
• При сбое продолжайте с последнего известного курсора;
• Используйте таймауты соединения и повторные попытки (retry logic).

Распространённые шаблоны и примеры использования

Правильное именование ключей — основа эффективного поиска. Используйте осмысленные префиксы и разделители.

• user:123:profile — профиль пользователя;
• cache:product:456 — кэш товара;
• session:xyz — сессия;
• rate_limit:ip:192.168.0.1 — лимиты по IP.

Примеры полезных шаблонов:

Поиск всех сессий

SCAN 0 MATCH session:* COUNT 100

Очистка кэша товаров

DEL $(redis-cli --raw SCAN 0 MATCH cache:product:* COUNT 100 | xargs)

(Внимание: массовое удаление через подстановку может перегрузить сервер.)
Лучше использовать UNLINK вместо DEL:

UNLINK $(...)

UNLINK удаляет ключ асинхронно, не блокируя основной поток.

Поиск ключей по диапазону ID

Шаблон user:[1-9]*:data найдёт ключи, где ID начинается с цифры от 1 до 9. Однако он не различает числовые диапазоны — это важно учитывать.

Использование Lua-скриптов для сложных условий

Для поиска по составным условиям можно использовать EVAL с Lua:

EVAL "local keys = redis.call('SCAN', 0, 'MATCH', 'temp:*') return keys[2]" 0

Но будьте осторожны: Lua-скрипты тоже блокируют сервер, если выполняются долго.

Проблемы производительности и как их избежать

Поиск ключей — ресурсоёмкая операция, даже при использовании SCAN. Основные риски:

• Высокая нагрузка на CPU — каждый вызов SCAN требует вычислений;
• Сеть — передача тысяч ключей увеличивает трафик;
• Память — накопление списка ключей на клиенте может исчерпать RAM.

Как минимизировать влияние

1. Используйте максимально узкие шаблоны: logs:error:2026* вместо logs:*.
2. Устанавливайте адекватный COUNT: 100–500 обычно достаточно.
3. Выполняйте сканирование в периоды низкой нагрузки.
4. Не запускайте параллельные SCAN-операции — они суммируют нагрузку.

Альтернативы сканированию

• Хранение метаинформации: при создании ключа добавляйте его в Set или Sorted Set.

  ZADD keys_by_type 0 mykey:type1

• Использование RedisJSON или RediSearch: если данные структурированы, можно индексировать их и выполнять сложные запросы.
• Sharding по префиксам: распределяйте ключи по разным экземплярам Redis по типу (например, сессии → redis-sessions, кэш → redis-cache).

Лучшие практики работы с ключами в Redis

Чтобы избежать необходимости массового поиска, следуйте этим принципам:

• Стандартизируйте имена ключей. Используйте единые правила: префикс:сущность:id:атрибут.
• Ограничивайте TTL. Почти все ключи должны иметь срок жизни, чтобы избежать накопления мусора.
• Мониторьте объём данных. Используйте INFO memory и DBSIZE для отслеживания роста.
• Регулярно аудируйте ключи. Запускайте сканирование (в off-peak) для выявления устаревших или битых ключей.

Автоматизация поиска и очистки

Создайте скрипт, который:

• Находит ключи по шаблону с помощью SCAN;
• Фильтрует по TTL (если нужно);
• Удаляет или архивирует их через UNLINK или экспорт.

Пример cron-задачи:

0 2 * * * /opt/scripts/redis-cleanup.sh

Безопасность

• Ограничьте доступ к командам KEYS и FLUSHDB через ACL (Redis 6+).
• Запрещайте KEYS на production-инстансах.
• Используйте отдельные пользователи для административных операций.

Экспертное мнение

Поиск ключей по шаблону — это симптом, а не цель. Чаще всего он требуется, потому что отсутствует контроль над жизненным циклом данных. Лучший способ «найти все ключи» — не искать их вовсе, а организовать хранение так, чтобы нужные данные были доступны через индексы или метаданные.
Redis не является полноценной базой данных с запросами. Он оптимизирован под скорость, а не гибкость. Поэтому архитектурное решение — делегировать сложные поисковые операции другим системам: Elasticsearch, PostgreSQL с расширением для JSON или модулям типа RediSearch.
Тем не менее, SCAN остаётся важным инструментом администрирования. Его следует использовать осознанно, с учётом нагрузки и времени выполнения. Автоматизация, мониторинг и документирование схемы ключей сводят необходимость в ручном поиске к минимуму.

Вопросы и ответы

Заключение

Поиск ключей по шаблону в Redis — задача, требующая баланса между функциональностью и производительностью. Команда KEYS проста, но опасна в продакшене. SCAN — правильный выбор для реальных систем: она не блокирует сервер и позволяет контролировать нагрузку.
Главное — не доводить до ситуации, когда поиск становится частой необходимостью. Продуманная схема именования, использование TTL, индексация через Sets и мониторинг помогут избежать ручных операций. Redis создан для скорости, а не для аналитики. Если вам регулярно нужно искать или агрегировать данные — рассмотрите интеграцию с другими системами.

• Никогда не используйте KEYS в продакшене.
• Всегда применяйте SCAN с параметром MATCH и разумным COUNT.
• Стандартизируйте имена ключей и используйте префиксы.
• Ограничивайте TTL и регулярно очищайте устаревшие данные.
• Рассмотрите RediSearch или внешние индексы для сложных запросов.