Dragonfly: быстрая замена Redis

Redis больше десятилетия остаётся стандартом для кэша и очередей, но его ядро однопоточное: один экземпляр упирается в одно ядро, а частота процессоров почти не растёт. Dragonfly предлагает другой подход — многопоточный сервер с тем же протоколом RESP. Клиенты видят привычный Redis, а машина под ним использует все ядра и десятки гигабайт памяти.

Архитектура и совместимость

Dragonfly делит пространство ключей на сегменты, каждый обслуживает свой поток. Общие данные синхронизируются через разделяемую память, поэтому один экземпляр масштабируется вертикально. Для операций с несколькими ключами используют hash tags, чтобы ключи попали в один сегмент.

Протокол совместим с Redis и Memcached, поэтому подходят redis-cli, готовые клиенты и большинство библиотек. Но совместимость не абсолютна: модули вроде RediSearch или RedisJSON не поддерживаются, часть служебных команд отличается. Перед миграцией проверяют список используемых команд, а не только версию клиента.

Запуск в Docker

Самый быстрый способ познакомиться — контейнер с томом для снимков. Параметр —ulimit memlock=-1 снимает ограничение на блокировку памяти, иначе при больших объёмах возможны сюрпризы.

docker run -d --name dragonfly \
  --ulimit memlock=-1 \
  -p 6379:6379 \
  -v dragonfly-data:/data \
  docker.dragonflydb.io/dragonflydb/dragonfly \
  --maxmemory=8gb --proactor_threads=4

Проверка не отличается от Redis: тот же клиент, тот же ping. Если нужен пароль, добавьте —requirepass и не храните его в истории команд.

redis-cli -h 127.0.0.1 -p 6379 ping
redis-cli -p 6379 set session:42 active
redis-cli -p 6379 info memory
redis-cli -p 6379 dbsize

Параметры, которые важны

Настройки задают флагами командной строки или файлом. Для контейнера удобнее смонтировать файл с флагами в каталог конфигурации.

• —maxmemory — верхняя граница памяти; без неё процесс может занять всё.
• —proactor_threads — число потоков; обычно равно доступным ядрам.
• —cache_mode — режим кэша с вытеснением, близкий к memcached.
• —dir и —dbfilename — каталог и имя файла снимка.
• —snapshot_cron — расписание фоновых снимков.
• —replicaof — режим реплики с адресом мастера.

Значения по умолчанию рассчитаны на небольшую машину и почти всегда требуют правки. Отдельно проверьте лимиты контейнера: maxmemory должен быть меньше лимита памяти pod, иначе OOM-killer убьёт процесс раньше, чем сработает вытеснение.

Кэш или хранилище

В режиме кэша Dragonfly вытесняет ключи при достижении maxmemory и ведёт себя предсказуемо под нагрузкой. Без cache_mode превышение лимита приводит к ошибкам записи — это нормально для базы, где потеря ключа недопустима.

Выбор зависит от данных. Сессии, результаты запросов и счётчики переживут вытеснение. Очереди задач и блокировки — нет: для них нужен запас памяти, реплика и мониторинг. Смешивать оба сценария в одном экземпляре можно, но тогда кэш обязан иметь отдельный лимит или отдельный инстанс.

Отдельная тонкость — крупные значения. Многопоточность не помогает, если один ключ весит десятки мегабайт: такой запрос всё равно обрабатывается одним потоком и блокирует сегмент. Дробите большие объекты на части или храните их вне Redis-подобного хранилища.

Персистентность и репликация

Снимки пишутся в формате, совместимом с RDB, и загружаются при старте. Расписание задаёт cron, а ручной вызов доступен знакомой командой. Реплика подключается к мастеру и получает поток изменений; повышение выполняют вручную или с помощью оператора.

redis-cli -p 6379 info persistence
redis-cli -p 6379 save
redis-cli -p 6379 replicaof 10.0.0.10 6379
redis-cli -p 6379 info replication

Для отказоустойчивости одной реплики мало: нужен внешний арбитр или оркестратор, который переключит клиентов. В Kubernetes это делает оператор, в виртуальных машинах — связка с балансировщиком и health-check.

Замеры и диагностика

Сравнивать имеет смысл на своём профиле нагрузки. memtier_benchmark и redis-benchmark дают отправную точку, но решают не они, а задержка на ваших запросах.

memtier_benchmark -h 127.0.0.1 -p 6379 -t 4 -c 50 \
  --test-time=60 --ratio=1:9 --key-pattern=S:S
redis-cli -p 6379 --latency
redis-cli -p 6379 slowlog get 10
redis-cli -p 6379 info everything

Смотрите на p99, а не на среднее, и отдельно — на время вытеснения. Рост задержки при стабильном CPU часто означает нехватку памяти или слишком крупные значения. Метрики Prometheus отдаются по HTTP на admin-порту, если он включён.

Прогревайте стенд перед измерениями и повторяйте прогон несколько раз: первый запуск включает прогрев страниц и аллокаторов. Сравнивайте одинаковые конфигурации потоков, иначе разница будет отражать настройки, а не движок.

Переезд с Redis

Сначала инвентаризация: какие команды, модули, скрипты и клиентские библиотеки используются. Затем Dragonfly поднимают рядом и направляют на него теневой трафик или тестовый контур. Рабочая схема — сделать Dragonfly репликой текущего Redis, дождаться синхронизации, остановить запись, повысить реплику и переключить клиентов.

Откат должен быть готов до переключения: старый экземпляр не удаляют, пока новый не отработает под нагрузкой хотя бы сутки. Отдельно проверяют TTL, поведение при вытеснении и работу скриптов. Клиентам заранее увеличивают таймауты и число повторов, иначе короткая пауза при переключении превратится в шквал ошибок.

Эксплуатация в Kubernetes

Оператор создаёт StatefulSet с постоянным томом и сервисом. В манифесте задают память, число потоков и расписание снимков; лимит памяти контейнера держат выше maxmemory на 20–30 процентов.

kubectl apply -f dragonfly.yaml
kubectl -n cache get pods,pvc
kubectl -n cache logs dragonfly-0 --tail=100
kubectl -n cache exec -it dragonfly-0 -- redis-cli info memory

Проверьте, что readiness-проба действительно отвечает на ping, а не просто открывает порт. При обновлении образа сначала меняют реплики, затем мастера, иначе будет короткий простой записи. Отдельно ограничьте ресурсы: без requests планировщик поставит pod на перегруженный узел, и задержки вырастут без видимой причины.

Чек-лист

• Список команд и модулей сверен с поддержкой.
• maxmemory ниже лимита контейнера, вытеснение проверено.
• Снимки пишутся по расписанию и восстанавливаются.
• Реплика и процедура повышения описаны.
• Алерты на память, p99 и ошибки записи настроены.

Итог

Dragonfly даёт знакомый Redis-протокол и лучше использует современное железо, но требует дисциплины: проверенной совместимости, явных лимитов памяти и готового плана отката. Если один экземпляр упирается в ядро или память, это разумный шаг. Если нужны модули Redis Stack, сначала убедитесь, что их чем заменить.