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

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

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

Понимание постоянства данных Redis

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

1. Снимки базы данных Redis (RDB)

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

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

Постоянство данных RDB сильно зависит от команды BGSAVE (фоновое сохранение). При запуске сохранения:

Форкинг: Redis форкирует основной процесс в дочерний.
Создание снимка: Дочерний процесс записывает весь набор данных в файл RDB на диске.
Основной поток не затрагивается (по большей части): Основной поток 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`	Хорошо (теряется ~1 секунда данных)	Хороший баланс; незначительные накладные расходы. Рекомендуется по умолчанию.
Без синхронизации	`no`	Плохо (зависит от буфера ОС)	Самый быстрый; максимальный риск потери данных при сбое ОС.
Всегда	`always`	Отлично (атомарная запись)	Самый медленный; значительное увеличение задержки из-за обязательного ввода-вывода на диск при каждой записи.

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

Задержка записи: При использовании 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 mode): Эта конфигурация является самой медленной, потому что задержка диска напрямую вносится в каждую команду записи клиента, что приводит к более высоким задержкам p99.
AOF (everysec mode): Это обеспечивает производительность, почти как у RDB, для большинства операций, поскольку операции fsync буферизуются и происходят реже.

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

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

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

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

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

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

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

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

Более быстрое восстановление: Если файл AOF поврежден или стал чрезвычайно большим, Redis может использовать самый последний снимок RDB в качестве отправной точки, значительно ускоряя последующий процесс воспроизведения AOF.
Эффективность перезаписи AOF: Redis может автоматически запускать операцию перезаписи AOF (которая генерирует новый, компактный файл AOF путем отбрасывания избыточных команд) на основе самого последнего снимка 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 включает форкинг процесса. Если ваша система ограничена по памяти, это временное удвоение использования памяти (работающий экземпляр плюс перезаписываемая копия) может привести к нестабильности или свопингу.

Заключение

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

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