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

Redis, хранилище структур данных в памяти, известен своей скоростью и универсальностью как кэш, хранилище сессий и брокер сообщений. Хотя его основная операция выполняется в памяти, обеспечение долговечности и восстанавливаемости данных часто имеет решающее значение для промышленных развертываний. Именно здесь вступает в игру персистентность Redis, позволяющая сохранять состояние вашего набора данных на диск.

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

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

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

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

RDB (Резервное копирование базы данных Redis): моментальный снимок вашего набора данных на определенный момент времени.
AOF (Файл только для добавления): журнал каждой операции записи, выполненной сервером.

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

Резервное копирование базы данных Redis (RDB)

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

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

Создание дочернего процесса (Forking): Сервер Redis создает новый дочерний процесс.
Создание снимка (Snapshotting): Дочерний процесс начинает записывать весь набор данных во временный RDB-файл.
Завершение (Completion): Как только дочерний процесс завершает запись, он заменяет старый RDB-файл новым временным.
Очистка (Cleanup): Дочерний процесс завершает работу.

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

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

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

Недостатки RDB

Потенциальная потеря данных: Главный недостаток — это потенциальная потеря данных. Если Redis выйдет из строя между точками сохранения, все данные, записанные с момента последнего успешного сохранения RDB, будут потеряны.
Скачок производительности во время fork: Для очень больших наборов данных первоначальная операция 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.

Файл только для добавления (AOF)

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

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

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

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

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

Недостатки AOF

Больший размер файла: AOF-файлы обычно намного больше, чем RDB-файлы для того же набора данных, потому что они хранят команды, а не компактные данные.
Более медленное восстановление: Повторное воспроизведение большого AOF-файла при запуске может быть медленнее, чем загрузка RDB-файла, поскольку Redis необходимо выполнить каждую команду.
Влияние на производительность: В зависимости от политики fsync, AOF может вызывать больший дисковый ввод-вывод, потенциально влияя на производительность записи. appendfsync always особенно сильно влияет.
Накладные расходы на перезапись AOF: Хотя перезапись AOF помогает управлять размером файла, сам процесс перезаписи потребляет ресурсы ЦП и ввода-вывода и может временно блокировать Redis, если набор данных очень велик, аналогично fork в 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 (Файл только для добавления)
Механизм	Моментальные снимки на определенный момент времени (бинарный файл)	Журнал всех операций записи (текстовые команды)
Потеря данных	Потенциальная потеря данных между точками сохранения (минуты)	Минимальная потеря данных (секунды с `everysec`, нет с `always`)
Производительность	Более высокая производительность записи при обычных операциях, потенциальная блокировка при `fork()`	Более медленная запись с сильной `fsync`, более последовательный ввод-вывод
Размер файла	Очень компактные бинарные файлы	Обычно больше, растет с операциями
Время восстановления	Быстрее для больших наборов данных	Медленнее для больших наборов данных (повторное воспроизведение команд)
Простота резервного копирования	Единый, компактный файл; легко для резервного копирования/аварийного восстановления	Больший файл, потенциально сложнее в управлении без перезаписи
Читаемость	Нечитаем для человека	Читаем для человека (команды)
По умолчанию в Redis	Да (с директивами `save`)	Нет (по умолчанию `appendonly no`)

Гибридный подход: RDB и AOF вместе (Redis 4.0+)

Начиная с Redis 4.0, возможно и часто рекомендуется комбинировать персистентность RDB и AOF. Когда оба включены, Redis будет преимущественно использовать AOF-файл для восстановления набора данных при запуске, поскольку он гарантирует лучшую долговечность. Однако процесс перезаписи AOF в Redis 4.0+ также создает гибридный AOF-файл, который начинается с преамбулы RDB, а затем добавляет команды AOF. Это сочетает в себе лучшее из обоих миров:

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

Чтобы включить этот гибридный режим, просто настройте appendonly yes и ваши директивы save для RDB.

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

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

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

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

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

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

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

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

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

Мониторинг использования диска: Как 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, и AOF предлагают отличные преимущества и компромиссы. RDB обеспечивает компактные моментальные снимки для быстрых перезапусков и резервного копирования, идеально подходящие для менее критичных данных или периодического архивирования. AOF обеспечивает превосходную долговечность, регистрируя каждую команду, что делает его подходящим для критически важных наборов данных, где минимальная потеря данных имеет первостепенное значение.

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