Redis Persistence

Redis Persistence — это комплекс механизмов, отвечающих за сохранение данных из оперативной памяти на долговечный носитель (жесткий диск или SSD).

Redis — это in-memory база данных. Это означает, что по умолчанию все данные живут исключительно в оперативной памяти. Это обеспечивает феноменальную скорость, но создает критический риск: при любом сбое питания, перезагрузке сервера или аварийном завершении процесса все накопленные данные исчезнут безвозвратно. Чтобы превратить Redis из быстрого кэша в надежное хранилище, необходимо настроить персистентность.

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

• RDB (Redis Database): Периодические снимки состояния базы данных.

• AOF (Append-Only File): Журнал, логирующий каждую операцию записи.

Понимание различий между ними критически важно для построения надежной системы. Неправильный выбор стратегии может привести либо к потере важных бизнес-данных, либо к существенной деградации производительности сервера.

RDB (Redis Database) — Стратегия Snapshot «Фотоаппарат»

Механизм RDB работает по принципу создания точечных снимков (снэпшотов) всего набора данных через заданные промежутки времени. Это компактное бинарное представление базы данных на определенный момент времени.

Конфигурация обычно задается правилами вида «время-изменения». Например, директива save 300 10 приказывает Redis создать снимок, если прошло 300 секунд (5 минут) и было изменено не менее 10 ключей. Можно задать несколько таких правил одновременно.

Как работает RDB (Механизм Fork)

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

Алгоритм выглядит следующим образом:

1. Основной процесс Redis создает свою точную копию (дочерний процесс).

2. Родительский процесс продолжает обслуживать клиентов, не блокируясь на время записи.

3. Дочерний процесс начинает записывать содержимое памяти в временный RDB-файл на диске.

4. Как только запись завершена, временный файл атомарно заменяет старый RDB-файл.

Визуализация этого процесса до и после аварии представлена ниже.

Этот подход идеален для создания резервных копий. Файл RDB очень компактен и быстро загружается при старте. Однако, если авария произойдет через 14 минут после последнего снимка, вы потеряете данные за эти 14 минут.

AOF (Append Only File) — Стратегия «Бортовой журнал»

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

Этот механизм решает главную проблему RDB — потерю данных в промежутке между снимками. С включенным AOF Redis записывает каждую команду записи (например, SET, INCR) в конец специального файла. При перезагрузке сервер просто «проигрывает» этот журнал с первой до последней команды, восстанавливая состояние памяти байт в байт.

Как это работает (Буфер и Синхронизация)

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

1. Клиент отправляет команду.

2. Redis выполняет её в памяти.

3. Команда добавляется в AOF-буфер (в оперативной памяти).

4. Операционная система сбрасывает буфер на диск (fsync).

При перезагрузке Redis просто «проигрывает» этот журнал с начала до конца, восстанавливая состояние. Ключевой момент здесь — частота сброса на диск (fsync). От этого зависит баланс между скоростью и безопасностью. Настройка надежности (fsync). Ключевой параметр — appendfsync. Он определяет, как часто сбрасывать буфер записи на диск:

• always: Синхронизация после каждой команды. Самый надежный, но очень медленный вариант. Убивает производительность.
• everysec: Синхронизация раз в секунду. Это стандарт по умолчанию. В худшем случае вы потеряете данные за 1 секунду.
• no: Отдает управление операционной системе (обычно раз в 30 секунд). Быстро, но рискованно.

Главная проблема AOF — размер. Если вы 100 раз измените счетчик, в RDB будет одно значение, а в AOF — 100 записей. Чтобы файл не раздувался до гигабайтов, Redis использует механизм AOF Rewrite (BGREWRITEAOF) . Он фоном пересоздает файл, оставляя только актуальные данные.

Сравнительная таблица режимов Redis persistence RDB и AOF

Выбор зависит от того, что для вас важнее: скорость восстановления или минимизация потерь.

Часто инженеры включают оба механизма одновременно.

Убийца памяти: Copy-on-Write

Это технический нюанс, о котором часто забывают, пока сервер не упадет с ошибкой OOM (Out Of Memory).

Когда Redis делает fork() для создания RDB или AOF Rewrite, операционная система не копирует всю память физически. Она использует оптимизацию Copy-on-Write (CoW). Дочерний и родительский процессы читают одну и ту же память. Но как только родительский процесс (основной Redis) пытается изменить какой-то ключ, ОС вынуждена скопировать страницу памяти, где лежит этот ключ, для дочернего процесса. Что это значит на практике?

Если у вас занято 10 ГБ памяти и идет активная запись во время сохранения бэкапа, потребление RAM может внезапно вырасти до 20 ГБ. Если на сервере нет запаса памяти, придет OOM Killer и убьет процесс Redis. Всегда оставляйте запас RAM (желательно 30-50%).

Рецепты настройки Redis persistence (Сценарии)

Универсального конфига не существует. Настройки зависят от роли Redis в вашей архитектуре. Рассмотрим три типовых сценария:

• Чистый кэш (Cache Only)
  Если данные можно восстановить из БД, выключайте всё. Это даст максимальную скорость.

  save ""
  appendonly no

• Разумная надежность (General Purpose)
  Золотая середина. Используем RDB для бэкапов и AOF для надежности.

  save 900 1
  save 300 10
  appendonly yes
  appendfsync everysec

• Hybrid Persistence (Redis 5.0+)
  Лучший выбор для современных версий. Включается директивой aof-use-rdb-preamble yes.
  В этом режиме AOF-файл начинается с RDB-снимка, а следом идут дозаписанные команды. Это дает быстрый рестарт (как у RDB) и надежность (как у AOF).

Использование гибридного режима стало стандартом де-факто.

Восстановление после сбоя (Crash Recovery) для Redis persistence

Когда Redis перезагружается, ему нужно решить, откуда восстанавливать данные. Логика выбора источника жестко задана алгоритмом, чтобы минимизировать потери. Приоритеты загрузки выглядят так:

Если включен AOF: Redis всегда выберет его.

• Причина: AOF считается более полным источником истины, так как в нем (в режиме everysec) максимум 1 секунда потерь. RDB всегда будет более старым.

Если AOF выключен: Redis загрузит последний RDB-файл.

• Риск: Данные будут восстановлены только на момент последнего снимка (например, 10 минут назад).

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

Для починки существуют встроенные утилиты:

• Сделайте бэкап поврежденного файла (обязательно!).
• Запустите redis-check-aof —fix appendonly.aof.
• Утилита просканирует файл, найдет место сбоя и обрежет его до последней валидной транзакции.

Для RDB существует аналог redis-check-rdb, но он чаще используется просто для проверки целостности. Используя эту стратегию, вы превращаете Redis из временного кэша в надежное хранилище, способное пережить падение сервера.

Заключение

Вопрос «RDB или AOF?» в 2026 году решается просто — используйте оба в гибридном режиме. Это дает скорость восстановления снимков и надежность журнала операций.

Однако помните про память. Персистентность — это не бесплатно. Следите за метрикой cow_size в логах и никогда не забивайте оперативную память под завязку, если включено сохранение на диск.

Референсные ссылки

• Redis Persistence Documentation
• Redis persistence demystified
• Top Redis Headaches for Devops (OOM and CoW)