Персистентность Redis: RDB или AOF и как не потерять данные

Коротко: RDB, AOF и что выбрать

Redis держит данные в памяти, а на диск сохраняет их одним из двух способов:

• RDB — периодический снимок всей базы в компактный бинарный файл.
• AOF (Append Only File) — журнал всех операций записи, который при перезапуске проигрывается заново.

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

Как работает RDB

По правилам save Redis вызывает fork(): дочерний процесс пишет снимок на диск, а основной продолжает обслуживать клиентов.

# снимок, если за 3600 с было хотя бы 1 изменение,
# за 300 с — 100 изменений, за 60 с — 10000 изменений
save 3600 1 300 100 60 10000
dbfilename dump.rdb

Что важно знать:

• Всё, что записано после последнего снимка, при падении теряется.
• fork() использует copy-on-write: пока идёт снимок, изменяемые страницы памяти копируются. При активной записи серверу нужен запас RAM.
• На Linux документация Redis рекомендует vm.overcommit_memory = 1, иначе фоновое сохранение может падать.

Как работает AOF и политики fsync

Каждая команда записи дописывается в журнал. Как часто журнал реально сбрасывается на диск, задаёт appendfsync:

everysec — значение по умолчанию и разумный компромисс для большинства задач.

Журнал постоянно растёт, поэтому Redis периодически переписывает его в компактную форму (BGREWRITEAOF), тоже через fork(). Частоту задают auto-aof-rewrite-percentage и auto-aof-rewrite-min-size.

Гибридный режим

При aof-use-rdb-preamble yes переписанный AOF начинается со снимка в формате RDB, а дальше идут только новые команды. Это даёт быстрый старт как у RDB и надёжность как у AOF. Если включён AOF, при запуске Redis восстанавливает данные именно из него.

Память и вытеснение

maxmemory ограничивает объём данных, а maxmemory-policy решает, что делать, когда лимит достигнут:

• noeviction — новые записи получают ошибку, ничего не удаляется;
• allkeys-lru / allkeys-lfu — удаляются давно или редко используемые ключи среди всех;
• volatile-lru / volatile-lfu / volatile-ttl — удаляются только ключи с TTL;
• allkeys-random / volatile-random — случайные ключи.

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

Чек-лист: Redis как кэш

maxmemory 2gb
maxmemory-policy allkeys-lru
save ""
appendonly no

• Приложение должно уметь работать с пустым кэшем и заполнять его из основной базы.
• Ставьте TTL на ключи.
• Если холодный старт после перезапуска слишком тяжёл для базы, оставьте редкие RDB-снимки.

Чек-лист: Redis как основное хранилище сессий или очередей

appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
save 3600 1 300 100 60 10000
maxmemory 2gb
maxmemory-policy noeviction

• noeviction для очередей обязателен; для сессий допустим volatile-lru, если повторный вход пользователя — приемлемая цена.
• Мониторьте использование памяти и ошибки записи, чтобы лимит не стал сюрпризом.
• Держите запас RAM под fork().
• Копируйте RDB-файлы на другой сервер или в объектное хранилище. Репликация не заменяет бэкап: удаление ключа мгновенно уйдёт и на реплику.
• Регулярно проверяйте восстановление из бэкапа на тестовом сервере.
• Для критичных данных добавьте реплику и автоматическое переключение.