Сравнение компромиссов производительности персистентности AOF и RDB

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

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

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

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

1. Снапшоты базы данных Redis (RDB)

RDB создает компактный, мгновенный снимок всего набора данных через заданные интервалы. Он сохраняет эти данные в бинарный файл (dump.rdb).

Как работает RDB и его влияние на производительность

Персистентность RDB в значительной степени полагается на команду BGSAVE (Фоновое сохранение). Когда сохранение запускается:

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

Соображения производительности:

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

Настройка сохранений RDB

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

save 900 1     # Сохранить, если 1 ключ изменился за 900 секунд (15 минут)
save 300 10    # Сохранить, если 10 ключей изменились за 300 секунд (5 минут)
save 60 10000  # Сохранить, если 10000 ключей изменились за 60 секунд (1 минута)

2. Персистентность с помощью файла только для добавления (AOF)

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

Как работает AOF и его влияние на производительность

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

Политики Fsync AOF:

Политика	Настройка appendfsync	Долговечность	Влияние на производительность
Каждую секунду	everysec	Хорошая при нормальной работе; сбой может привести к потере примерно одной секунды подтвержденных записей	Хороший баланс; распространенный выбор в производстве.
Без синхронизации	no	Плохая (полагается на буфер ОС)	Самый быстрый; максимальный риск потери данных при сбое ОС.
Всегда	always	Самая строгая политика долговечности AOF	Самый медленный; значительное увеличение задержки из-за синхронизации диска при каждой записи.

Соображения производительности:

• Задержка записи: При использовании appendfsync always каждая команда записи влечет за собой задержку синхронизации диска, что значительно замедляет операции по сравнению с RDB или операциями в памяти. Использование everysec значительно смягчает это за счет пакетной обработки fsync.
• Время восстановления: Файлы AOF могут стать большими, и воспроизведение миллионов команд может занять больше времени, чем загрузка компактного файла RDB, что приводит к более высокой задержке восстановления.
• Размер файла: Файлы AOF обычно намного больше, чем файлы RDB, потому что они хранят команды (например, SET key value), а не конечное состояние структуры данных.

Включение и настройка AOF

AOF отключен по умолчанию и включается установкой appendonly yes в redis.conf. Ключевой настройкой является appendfsync:

appendonly yes
appendfilename "appendonly.aof"
# Рекомендуемая настройка для компромисса между долговечностью и скоростью
appendfsync everysec 

Анализ компромиссов производительности: AOF против RDB

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

Задержка и пропускная способность

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

Долговечность и риск потери данных

• AOF (лучший для долговечности): Обеспечивает самую высокую долговечность, особенно с appendfsync always. Даже с everysec потеря данных ограничивается одной секундой.
• RDB (худший для долговечности): Потеря данных может составлять минуты или часы, в зависимости от расписания сохранений.

Время восстановления

• RDB (быстрое восстановление): Более быстрое время перезапуска благодаря оптимизированному компактному бинарному формату.
• AOF (медленное восстановление): Воспроизведение большого журнала команд может занять больше времени, чем загрузка снапшота, что увеличивает время простоя во время перезапусков.

Лучшая практика: использование обоих методов персистентности

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

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

Зачем использовать оба?

1. Лучший выбор для восстановления: Redis обычно загружает AOF первым, когда оба включены, потому что он обычно более полный. Сохранение RDB дает вам дополнительный резервный артефакт для резервного копирования и аварийного восстановления.
2. Операционная гибкость: RDB компактен и легко архивируется, в то время как AOF сужает окно потери данных. Вместе они покрывают различные режимы отказов.

Фрагмент конфигурации для обоих:

# 1. Включить RDB
save 900 1

# 2. Включить AOF с синхронизацией 'everysec'
appendonly yes
appendfsync everysec

Управление размером файла AOF (перезапись)

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

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

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

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

Вывод

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