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

"Если AOF записывает данные в реальном времени, имеет ли смысл настраивать RDB?" "Раз AOF имеет приоритет при восстановлении, не является ли RDB лишним?"

Однако в реальной производственной среде RDB также необходим. Давайте рассмотрим причины.

Инфографика Redis RDB против AOF

1. Файл AOF может быть поврежден

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

redis-server --appendonly yes

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

✅ Что, если использовать только AOF и файл будет поврежден? Повышенный риск потери данных

✅ Что, если есть RDB? Возможно восстановление хотя бы минимальных данных

2. Скорость восстановления AOF медленная

AOF необходимо восстановить, последовательно выполняя все изменения. Чем больше данных, тем дольше время восстановления при перезапуске Redis.

Например, если файл AOF имеет размер 2 ГБ, Redis должен выполнить миллионы команд SET. В то время как RDB просто загружает дамп-файл, что позволяет гораздо быстрее выполнить восстановление.

✅ Что, если использовать только AOF? Риск увеличения времени восстановления

✅ Что, если использовать RDB? Возможное быстрое восстановление

3. RDB удобен для резервного копирования и миграции серверов

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

✔ Пример резервного копирования с использованием RDB:

cp /var/lib/redis/dump.rdb /backup/dump-2025-02-17.rdb

✔ Пример переноса данных на другой сервер:

scp /var/lib/redis/dump.rdb new-server:/var/lib/redis/

✅ AOF сложнее резервировать, когда данных много

✅ RDB удобен для быстрого резервного копирования и восстановления данных на определенный момент времени

4. Можно снизить нагрузку на дисковый I/O

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

✅ Что, если использовать только AOF? Возможное увеличение нагрузки на диск

✅ Что, если использовать RDB совместно? Возможная оптимизация производительности

5. Рекомендуемая настройка RDB + AOF в производственной среде

В производственной среде рекомендуется следующая настройка.

# Настройка снимка RDB (сохранять данные на диск при выполнении условий)
# save <seconds> <changes> [<seconds> <changes> ...]
save 900 1 300 10 60 10000 
# Сохранить через 900 секунд (15 минут) при изменении более 1 ключа, или 300 секунд (5 минут) при изменении более 10 ключей, или 60 секунд (1 минута) при изменении более 10,000 ключей

# Включение AOF
appendonly yes
appendfsync everysec  # Запись на диск каждую секунду для балансировки производительности и надежности

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

🔍 Как оцениваются несколько условий save?

В Redis все условия save работают как условие OR. То есть, достаточно, чтобы выполнено было лишь одно условие, чтобы сохранить снимок.

✔ Пример 1: если установлены save 900 1 и save 60 10000 - если изменится более 1 ключа за 900 секунд, или более 10,000 ключей за 60 секунд - будет сохранен снимок RDB.

✔ Пример 2: если добавлено условие save 300 10 - если в течение 300 секунд изменится более 10 ключей, или более 1 ключа в течение 900 секунд, или более 10,000 изменений за 60 секунд - будет сохранен снимок RDB.

✅ Все опции save оцениваются как условие OR

✅ Если выполнено хотя бы одно условие, RDB будет сохранен немедленно

Заключение: RDB необходим даже с AOF

✅ AOF недостаточно для полной защиты данных

✅ Если AOF повредится, RDB станет последней защитой

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

✅ RDB удобно для резервного копирования и миграции серверов

✅ Можно снизить нагрузку на дисковый I/O и оптимизировать производительность

✅ Настройки save работают по условию OR: если одно из условий выполнено, RDB сохраняется

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

Попробуйте поискать `Redis` в правом верхнем углу! Здесь есть и другие посты, связанные с Redis. 

Также ознакомьтесь с предыдущей статьей, в которой проведен анализ функции AOF Rewrite.

Redis AOF Rewrite: оптимизация производительности и сохранение данных