Выбор лучшей стратегии сохранения Redis: RDB против AOF.

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

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

Понимание сохранения Redis

Сохранение в Redis означает возможность сохранять набор данных в памяти на диск, чтобы его можно было перезагрузить после перезапуска сервера или сбоя. Без сохранения все данные, хранящиеся в Redis, будут потеряны при остановке или сбое сервера. Redis предлагает два различных метода для достижения этого:

• RDB (Redis Database): Мгновенный снимок вашего набора данных на определенный момент времени.
• AOF (Append-Only File): Журнал каждой операции записи, выполняемой сервером.

Оба метода имеют свои характеристики и подходят для разных сценариев.

Redis Database (RDB)

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

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

1. Форкинг: Сервер Redis создает новый дочерний процесс.
2. Создание снимка: Дочерний процесс начинает запись всего набора данных во временный файл RDB.
3. Завершение: После завершения записи дочерний процесс заменяет старый файл RDB новым временным.
4. Очистка: Дочерний процесс завершается.

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

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

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

Недостатки RDB

• Потенциальная потеря данных: Основной недостаток — возможность потери данных. Если Redis выйдет из строя между точками сохранения, все данные, записанные с момента последнего успешного сохранения RDB, будут потеряны.
• Скачок производительности во время форкинга: Для очень больших наборов данных начальная операция fork() может быть медленной и блокировать сервер Redis на короткое время, особенно при высоком использовании памяти.
• Не сохранение в реальном времени: RDB не предназначен для сохранения данных в реальном времени. Он лучше всего подходит для сценариев, где потеря нескольких минут данных приемлема.

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

Сохранение RDB включено по умолчанию в redis.conf с помощью директивы save. Вы можете указать несколько правил save:

# Сохранять базу данных каждые 900 секунд (15 минут), если изменился хотя бы 1 ключ
save 900 1

# Сохранять базу данных каждые 300 секунд (5 минут), если изменилось хотя бы 10 ключей
save 300 10

# Сохранять базу данных каждые 60 секунд, если изменилось хотя бы 10000 ключей
save 60 10000

# Отключить сохранение RDB (закомментировать все директивы save или явно установить ниже)
# save ""

Вы также можете вручную запустить сохранение RDB с помощью команд SAVE (блокирующая) или BGSAVE (неблокирующая) в redis-cli.

Append-Only File (AOF)

Сохранение AOF регистрирует каждую операцию записи, полученную сервером Redis. Вместо периодического сохранения всего набора данных AOF записывает команды, которые изменяют набор данных. Когда Redis перезапускается, он повторно выполняет эти команды из файла AOF для восстановления исходного набора данных.

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

1. Регистрация команд: Каждая команда записи, выполненная Redis, добавляется в файл AOF.
2. Политика fsync: Redis имеет различные политики fsync для управления частотой синхронизации буфера AOF с диском:
   • appendfsync always: Синхронизация после каждой команды. Обеспечивает наилучшую надежность, но является самой медленной.
   • appendfsync everysec: Синхронизация раз в секунду. Это хороший баланс между надежностью и производительностью (по умолчанию и рекомендуется).
   • appendfsync no: Полагается на операционную систему для сброса буфера AOF на диск. Обеспечивает наилучшую производительность, но наименьшую надежность.
3. Перезапись AOF: Со временем файл AOF может сильно вырасти из-за избыточных команд (например, обновление одного и того же ключа несколько раз). Перезапись AOF оптимизирует файл AOF, создавая новый, меньший файл AOF, содержащий только необходимые команды для восстановления текущего набора данных. Этот процесс похож на механизм форкинга RDB.

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

• Лучшая надежность: С appendfsync always или everysec AOF обеспечивает более высокую надежность, чем периодические снимки RDB. С everysec Redis обычно ограничивает потерю примерно одной секундой подтвержденных записей, хотя сбои операционной системы или диска все еще могут повлиять на надежность.
• Меньше потери данных: В случае сбоя вы теряете значительно меньше данных, если вообще теряете, в зависимости от вашей политики fsync.
• Проверяемый формат: AOF хранит команды протокола Redis, поэтому его можно легче проверить и восстановить с помощью инструментов Redis, чем файл RDB.

Недостатки AOF

• Больший размер файла: Файлы AOF обычно намного больше, чем файлы RDB для того же набора данных, потому что они хранят команды, а не компактные данные.
• Медленное восстановление: Воспроизведение большого файла AOF при запуске может быть медленнее, чем загрузка файла RDB, так как Redis должен выполнять каждую команду.
• Влияние на производительность: В зависимости от политики fsync AOF может создавать больше дискового ввода-вывода, потенциально влияя на производительность записи. appendfsync always особенно сильно влияет.
• Накладные расходы на перезапись AOF: Хотя перезапись AOF помогает управлять размером файла, сам процесс перезаписи потребляет ресурсы ЦП и ввода-вывода и может временно блокировать Redis, если набор данных очень большой, аналогично форкингу RDB.

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

Чтобы включить AOF, необходимо установить appendonly yes в вашем redis.conf:

# Включить сохранение AOF
appendonly yes

# Имя файла только для добавления (по умолчанию: "appendonly.aof")
appendfilename "appendonly.aof"

# Опции appendfsync: always, everysec, no
appendfsync everysec

# Автоматически перезаписывать файл AOF, когда он вдвое больше базового и не менее 64 МБ
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB против AOF: Сравнительный обзор

Особенность	RDB (Резервное копирование базы данных Redis)	AOF (Файл только для добавления)
Механизм	Мгновенные снимки (двоичный файл)	Журнал операций записи в формате протокола Redis
Потеря данных	Потенциальная потеря между точками сохранения	Обычно около одной секунды с everysec; самая сильная с always
Производительность	Более высокая производительность записи при обычных операциях, возможная блокировка при fork()	Более медленная запись с сильным fsync, более стабильный ввод-вывод
Размер файла	Очень компактные двоичные файлы	Обычно больше, растет с операциями
Время восстановления	Быстрее для больших наборов данных	Медленнее для больших наборов данных (воспроизведение команд)
Легкость резервного копирования	Один компактный файл; легко для резервного копирования/аварийного восстановления	Больший файл, потенциально сложнее управлять без перезаписи
Читаемость	Не читается человеком	Более проверяемый, чем RDB
По умолчанию в Redis	Да (с директивами save)	Нет (appendonly no по умолчанию)

Гибридный подход: RDB и AOF вместе

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

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

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

Выбор правильной стратегии сохранения

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

1. Когда использовать только RDB

• Основной вариант использования: Кэш / Некритичные данные: Если Redis в основном используется как кэш, где потеря некоторых данных при сбое приемлема, или если ваши данные могут быть легко восстановлены из другого источника.
• Высокие требования к производительности: Когда производительность записи имеет первостепенное значение, а периодическая потеря данных допустима.
• Резервное копирование для аварийного восстановления: Файлы RDB отлично подходят для создания периодических снимков для долгосрочного архивирования или аварийного восстановления. Вы можете настроить cron для BGSAVE, а затем переместить файл .rdb в другое место.
• Эффективность памяти: Если у вас сильные ограничения по дисковому пространству.

2. Когда использовать только AOF

• Основной вариант использования: Абсолютная надежность: Когда каждая отдельная операция записи критична и потеря даже нескольких секунд данных неприемлема (например, финансовые транзакции, критически важные пользовательские данные). В этом случае можно рассмотреть appendfsync always, хотя это сопряжено со значительными затратами производительности.
• Отладка/Аудит: Человекочитаемая природа AOF может быть полезна для понимания изменений данных.

3. Когда использовать и RDB, и AOF (рекомендуется для большинства критических приложений)

• Сбалансированная надежность и восстановление: Обычно это рекомендуемый подход для производственных систем, где важна надежность данных, но также нужны эффективные перезапуски и резервное копирование.
• Устойчивость: Обеспечивает дополнительный уровень защиты. Если один метод сохранения будет поврежден, вы все еще сможете восстановиться с помощью другого.
• Гибридный AOF: Используйте формат AOF с преамбулой RDB, где это поддерживается и включено.

Практические советы и лучшие практики

• Мониторинг использования диска: Как RDB, так и AOF могут потреблять значительное дисковое пространство. Следите за использованием диска, чтобы не закончилось место, особенно перед перезаписью AOF или сохранением RDB.
• Политика fsync: Для AOF appendfsync everysec является наиболее распространенным и рекомендуемым выбором, предлагая хороший баланс между надежностью и производительностью. Избегайте appendfsync no для критических данных.
• Перезапись AOF: Настройте auto-aof-rewrite-percentage и auto-aof-rewrite-min-size осторожно, чтобы файлы AOF оптимизировались регулярно без чрезмерного потребления ресурсов.
• Отдельные диски/расположения: Если возможно, храните файлы сохранения (AOF и RDB) на другом диске или разделе, чем ваша операционная система и журналы приложений, чтобы предотвратить конкуренцию за ввод-вывод.
• Внешние резервные копии: Независимо от вашей стратегии сохранения, регулярно создавайте резервные копии ваших файлов RDB и AOF во внешнем расположении (например, S3, Google Cloud Storage) для надежного аварийного восстановления.
• Тестирование восстановления: Периодически тестируйте процесс восстановления с выбранной стратегией сохранения, чтобы убедиться, что данные могут быть успешно восстановлены.

Вывод

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