Варианты персистентности Redis: RDB против AOF

Персистентность Redis определяет, сколько данных ваш сервер Redis может восстановить после перезапуска или сбоя. Два основных варианта — это снапшоты RDB и журналы AOF, и правильный выбор зависит от того, сколько недавних данных ваше приложение может позволить себе потерять.

Redis хранит данные в памяти для скорости. Персистентность записывает достаточно состояния на диск, чтобы Redis мог позже восстановить эти данные. Вы можете использовать RDB, AOF, оба или ни один из них, но производственные системы должны делать этот выбор осознанно.

Понимание персистентности Redis

Персистентность в Redis относится к процессу записи текущего состояния набора данных в памяти на диск. Это позволяет Redis перезагрузить данные при перезапуске сервера. Без включенной персистентности все данные теряются при выключении.

Redis поддерживает одновременное использование RDB и AOF, предлагая гибридный подход, который объединяет лучшие функции обоих.

Снапшоты RDB

RDB создает мгновенные снимки вашего набора данных и записывает их в компактный бинарный файл, обычно называемый dump.rdb.

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

RDB обычно работает путем форка процесса Redis. Дочерний процесс записывает набор данных на диск, в то время как родительский продолжает обслуживать клиентов. Поскольку RDB — это снимок, он захватывает данные такими, какими они были в один момент.

Конфигурация и создание снимков

Конфигурация RDB управляется с помощью директив save в redis.conf. Эти директивы определяют, когда Redis должен создавать автоматический снимок:

# Сохранить БД, если 1000 ключей изменились за 1 минуту
save 600 1000
# Сохранить БД, если 10 ключей изменились за 10 минут
save 300 10
# Сохранить БД, если 10000 ключей изменились за 1 секунду
save 1 10000

Чтобы отключить автоматические снимки RDB, удалите директивы save или установите:

save ""

Вы все еще можете вручную запустить фоновый снимок с помощью BGSAVE, когда это необходимо.

Преимущества RDB

Компактные файлы: Файлы RDB эффективны для резервного копирования, копирования и архивов аварийного восстановления.
Быстрое восстановление: Загрузка одного снимка обычно быстрее, чем повторное воспроизведение длинного журнала команд.
Меньшая нагрузка на запись: Redis не записывает каждую команду в файл персистентности.

Недостатки RDB

Риск потери данных: Если Redis выйдет из строя между снимками, записи после последнего успешного снимка будут потеряны.
Накладные расходы на форк: Большие наборы данных могут сделать fork() дорогим и вызвать скачки задержки.
Не полный журнал аудита: RDB хранит конечное состояние, а не каждую запись, которая к нему привела.

Журналы AOF

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

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

Когда AOF включен, Redis записывает команды записи, такие как SET, HSET и LPUSH, в файл только для добавления. При перезапуске Redis воспроизводит этот файл для восстановления набора данных.

Конфигурация AOF

Персистентность AOF отключена по умолчанию и должна быть явно включена в redis.conf:

appendonly yes

Критически важно, что AOF позволяет настроить политику fsync, определяющую, как часто записи принудительно сбрасываются на диск:

Политика fsync	Описание	Надежность vs. Производительность
`no`	ОС управляет синхронизацией (наименее часто).	Самый быстрый, самый высокий риск потери.
`everysec`	Синхронизация примерно раз в секунду.	Хороший баланс. Обычно ограничивает потерю примерно одной секундой при сбое сервера.
`always`	Синхронизация после каждой команды.	Максимальная надежность, потенциально значительное снижение производительности.

Преимущества AOF

Более высокая надежность: appendfsync everysec — это распространенный производственный баланс; always строже, но медленнее.
Читаемое намерение: AOF хранит команды записи, поэтому его легче проверить, чем бинарный файл RDB.
Автоматическая компактификация: Перезапись AOF может сжать большой журнал до минимальных команд, необходимых для восстановления текущего состояния.

Недостатки AOF

Большие файлы: Файлы AOF часто больше, чем снимки RDB, потому что они хранят команды.
Более медленный перезапуск: Воспроизведение длинного AOF может занять больше времени, чем загрузка снимка RDB.
Больше накладных расходов на запись: Redis должен добавлять команды записи и синхронизировать их в соответствии с вашей настройкой appendfsync.

Перезапись AOF

Для борьбы с ростом размера файла Redis реализует перезапись AOF. Этот процесс асинхронно создает новый, оптимизированный файл AOF, содержащий только команды, необходимые для достижения текущего состояния, эффективно отбрасывая избыточные или устаревшие команды (например, множественные обновления одного и того же ключа).

RDB против AOF: Прямое сравнение

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

Особенность	RDB (Снимки)	AOF (Файл только для добавления)
Надежность/Потеря данных	Более высокая потенциальная потеря данных (с момента последнего сохранения).	Минимальная потеря данных (до 1 секунды или нулевая с `fsync=always`).
Размер файла	Очень компактный и оптимизированный.	Больше из-за регистрации команд.
Время перезапуска	Очень быстрая загрузка снимка.	Медленнее, требуется повторное воспроизведение команд.
Сложность	Простая, настраивается по временным интервалам.	Требует тщательной настройки политики `fsync`.
Сценарий использования	Резервное копирование, аварийное восстановление, где допустима потеря недавних данных.	Основной механизм персистентности, требующий высокой надежности.

Лучшая практика: Комбинирование RDB и AOF

Для многих производственных развертываний включение как RDB, так и AOF дает вам полезную страховочную сеть.

Когда оба включены:

AOF предоставляет основной, высоконадежный журнал.
RDB предоставляет быстрый, компактный резервный снимок.

Когда оба включены, Redis загружает AOF при перезапуске, потому что он обычно более полный, чем последний снимок RDB. RDB по-прежнему дает вам компактные файлы резервных копий, которые легко копировать, тестировать и архивировать.

Как включить оба

Убедитесь, что обе конфигурации установлены в redis.conf:

# Включить AOF
appendonly yes

# Сохранить конфигурацию RDB (например, автосохранение каждый час)
save 3600 1

# Рекомендуемая политика fsync для AOF
appendfsync everysec

Совет по перезаписи AOF: Вы можете вручную запустить перезапись AOF в любое время с помощью команды BGREWRITEAOF. Это особенно полезно после больших массовых загрузок данных или значительных операций очистки, чтобы немедленно уменьшить размер файла AOF.

Вывод

Используйте RDB, когда вам нужны компактные резервные копии и вы можете мириться с потерей недавних записей с момента последнего снимка. Используйте AOF, когда Redis хранит данные, которые должны пережить сбои с минимальными потерями. Для важных производственных данных включите AOF с appendfsync everysec, сохраняйте снимки RDB для резервного копирования и тестируйте время восстановления до того, как сбой заставит задать этот вопрос.