По умолчанию Redis — in-memory база данных. При рестарте все данные теряются. Для большинства сценариев это нормально, если Redis используется только как кэш. Но если в Redis хранятся очереди задач, сессии, счётчики или другие данные, которые нельзя потерять — нужна персистентность. Мы сталкивались с этим на каждом втором проекте: без RDB или AOF клиенты теряли операционные данные, и приходилось восстанавливать их из резервных копий вручную. Например, на проекте с очередями задач мы теряли до 5 минут данных между снэпшотами RDB, что приводило к задвоению заказов. После внедрения AOF с everysec потери сократились до 1 секунды. Настройка Redis Persistence — базовая задача для любого продакшн-сервиса с требованиями к сохранности данных. Рассмотрим оба механизма и их совместное использование.
Есть два механизма: RDB (снэпшоты) и AOF (append-only file). Их можно использовать по отдельности или вместе. Правильная конфигурация — фундамент надёжного восстановления с потерей не более секунды.
Как работает RDB?
RDB сохраняет полный снимок данных в бинарный файл dump.rdb. Настройка через директиву save:
save 900 1 save 300 10 save 60 10000 Это означает: сохранять если за 900 секунд изменился хотя бы 1 ключ, или за 300 секунд — 10 ключей, или за 60 секунд — 10000 ключей. При рестарте Redis загружает последний dump.rdb.
Главный минус RDB — потеря данных между снэпшотами. Если Redis упал за 5 минут до следующего снэпшота — потеряли 5 минут изменений. На high-load проектах это критично.
Согласно официальной документации Redis, снэпшот выполняется через fork() — создаётся дочерний процесс, который пишет данные на диск, пока родительский продолжает обслуживать запросы. На время fork() Redis может немного подвиснуть (latency spikes) — на большой базе (10+ GB) это может быть несколько секунд. Критично для low-latency применений.
Ручной снэпшот без блокировки: BGSAVE. С блокировкой (для backup): SAVE.
Что такое AOF?
AOF пишет каждую команду записи в лог-файл. При рестарте Redis воспроизводит весь AOF для восстановления данных.
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mbappendfsync — ключевой параметр:
- always — fsync после каждой команды. Максимальная надёжность, минимальная скорость.
- everysec — fsync каждую секунду. Потеря максимум 1 секунды данных при сбое. Баланс надёжности и производительности.
- no — fsync по решению ОС. Быстро, но потеря данных непредсказуема.
everysec — правильный выбор для большинства случаев.
AOF со временем растёт. auto-aof-rewrite-percentage 100 означает: когда файл удвоится относительно своего размера после последней перезаписи — запустить BGREWRITEAOF, который создаёт компактный AOF только с актуальными командами (без промежуточных SET/DEL одного ключа).
Подробнее о AOF rewrite
AOF rewrite использует дочерний процесс, аналогично BGSAVE, но вместо снэпшота создаёт новый компактный журнал. Во время rewrite Redis продолжает принимать запись в старый AOF. После завершения новый файл атомарно заменяет старый. Процесс управляется директивами auto-aof-rewrite-percentage и auto-aof-rewrite-min-size. Для крупных файлов (>10 GB) может потребоваться ручной запуск BGREWRITEAOF в часы низкой нагрузки.Почему стоит использовать оба механизма вместе?
При включении обоих механизмов при рестарте Redis использует AOF (он точнее). RDB остаётся как быстрый снэпшот для бэкапов.
save 900 1 appendonly yes appendfsync everysec Это рекомендуемая конфигурация для продакшна, где важна сохранность данных. Мы используем её на 80% проектов, включая high-load сервисы.
Как выбрать между RDB и AOF?
Сравним ключевые параметры:
| Параметр | RDB | AOF |
|---|---|---|
| Формат | Бинарный снэпшот | Журнал команд |
| Размер файла | Компактный | Больше (но rewrite помогает) |
| Потеря данных | Между снэпшотами (минуты) | До 1 сек (everysec) |
| Скорость восстановления | Быстрая (один файл) | Медленнее (воспроизведение команд) |
| Влияние на производительность | Fork + I/O at snapshot | I/O на каждую запись (fsync) |
| Ручное управление | BGSAVE / SAVE | BGREWRITEAOF |
Адаптация под конкретные сценарии:
| Сценарий | Рекомендуемый подход | Обоснование |
|---|---|---|
| Кэш (данные восстанавливаются) | Без персистентности | Максимальная производительность, нет fork |
| Очереди, сессии | RDB + AOF everysec | Гарантия восстановления с потерей не более 1 секунды |
| Счётчики, аналитика | Только AOF everysec | Компактнее, чем RDB, при частых записях |
| Микросервисы с low-latency | AOF everysec + disable fork | Избегаем latency spikes от fork |
Для сценария «только кэш»
Если Redis — чистый кэш, и при рестарте данные можно прогреть заново:
save "" appendonly no Выключить все механизмы персистентности. Redis будет быстрее (нет I/O на disk), и fork() для снэпшотов не будет вызывать latency spikes. Экономия ресурсов CPU и RAM — до 30% в зависимости от нагрузки.
Как мы настраиваем Redis Persistence под ключ
Процесс занимает от 2 до 3 дней в зависимости от объёма данных и требований к отказоустойчивости:
- Анализ нагрузки и сценариев — определяем, нужна ли персистентность, выбираем механизмы.
- Конфигурация — настройка save-интервалов, параметров AOF, rewrite, fsync.
- Тестирование восстановления — симулируем сбой, проверяем, что данные восстанавливаются за ожидаемое время.
- Мониторинг — добавляем метрики (RDB duration, AOF rewrite, fork latency) в Prometheus/Grafana.
- Документация и обучение — фиксируем runbook для дежурной смены.
Что входит в работу
- Конфигурация RDB и AOF через Ansible (Terraform).
- Тесты производительности и восстановления (результаты в отчёте).
- Мониторинг: дашборды Grafana, алерты по fork latency.
- Документирование runbook: как проверить, перезапустить, решить проблему.
- Обучение команды: 1 час онлайн с демонстрацией.
Частые ошибки при настройке
- Использование appendfsync always без необходимости — вызывает 10-кратное падение IOPS.
- Слишком частые save (каждые 60 секунд при 10k изменений) — перегрузка диска.
- Забывают про AOF rewrite — файл разрастается до десятков гигабайт.
- Настройка stop-writes-on-bgsave-error no — рискуете потерять данные при сбое снэпшота.
Гарантии и опыт
Стоимость настройки рассчитывается индивидуально в зависимости от сложности архитектуры. Гарантируем восстановление данных в заданные RTO/RPO при условии сохранности логов. Опыт работы с Redis — более 5 лет, 50+ успешных проектов в продакшне. Для оценки вашего проекта свяжитесь с нами — мы подберём оптимальную конфигурацию и проверим её на вашем стенде. Получите консультацию уже сегодня.
Закажите настройку Redis Persistence у опытных инженеров — обеспечим отказоустойчивость вашего сервиса.
