Redis: RDB vs AOF персистентность

25 апр 2026 · 10 мин чтения

Redis Базы данных

Два подхода к сохранению данных

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

RDB: снимки базы данных

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

# redis.conf
save 900 1
save 300 10
save 60 10000

# Запись дампа в /var/lib/redis/dump.rdb
dbfilename dump.rdb
dir /var/lib/redis/

Эти строки означают: сохранять снимок, если за 900 секунд было изменено хотя бы 1 ключ, за 300 секунд — 10 ключей, за 60 секунд — 10000 ключей. При большом количестве данных процесс fork() может потребовать столько же памяти, сколько использует основной процесс Redis.

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

Компактные файлы — удобно для бэкапов и передачи между инстансами
Восстановление происходит быстрее, чем из AOF
Минимальное влияние на производительность в часы пиковых нагрузок
Формат файла понятен и прост для анализа

Недостатки RDB

Возможна потеря данных между снимками — если Redis упадёт через 599 секунд после сохранения, все изменения за 10 минут пропадут
fork() может блокировать основной процесс при больших объёмах данных
Не подходит для ситуаций, где допустима потеря даже небольшого количества данных

AOF: журнал операций

AOF записывает каждую операцию модификации данных в отдельный файл. При восстановлении Redis последовательно воспроизводит все команды из журнала.

# redis.conf
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

# Три стратегии записи:
appendfsync always    # после каждой команды (медленно, но безопасно)
appendfsync everysec  # раз в секунду (компромисс, рекомендуется)
appendfsync no        # оставляем это ОС (быстро, но рискованно)

Перезапись AOF

AOF файл может расти очень быстро. Redis периодически выполняет перезапись (rewrite), записывая текущее состояние базы данных в компактном формате:

# Автоматическая перезапись AOF
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# Ручной запуск перезаписи
redis-cli BGREWRITEAOF

Сравнение производительности

При тестировании на 10 миллионах ключей с случайными строками по 100 байт:

RDB — восстановление за 12 секунд, файл 500 МБ
AOF always — запись команд замедляется на 40-50%
AOF everysec — падение производительности на 5-10%
AOF no — минимальное влияние на запись, но риски потери данных

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

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

Начиная с Redis 7.0, поддерживается гибридный режим персистентности:

# redis.conf
aof-use-rdb-preamble yes

При перезаписи AOF файл начинается с RDB-снипка, за которым следуют инкрементальные AOF-команды. Это даёт скорость восстановления RDB и надёжность AOF одновременно.

Настройка в Docker

# docker-compose.yml
services:
  redis:
    image: redis:7-alpine
    command: redis-server /etc/redis/redis.conf
    volumes:
      - ./redis.conf:/etc/redis/redis.conf
      - redis-data:/data

volumes:
  redis-data:

В контейнерах особенно важно настроить персистентность, так как при удалении контейнера volumes удаляются, если они не объявлены отдельно. Используйте именованные volumes или привязки к хостовой файловой системе.

Мониторинг

Отслеживайте ключевые метрики для понимания состояния персистентности:

# Проверка последнего времени сохранения
redis-cli LASTSAVE

# Статус AOF
redis-cli INFO persistence

# Ключевые поля:
# rdb_last_save_time — unix timestamp последнего RDB
# rdb_last_bgsave_status — "ok" или "err"
# aof_enabled — 1 если AOF включен
# aof_rewrite_in_progress — 1 если идёт перезапись

Вывод

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