Механизм сохранения Redis

Серия Redis

Принцип кэширования и дизайн серии Redis

Быстрый старт серии Redis

Структура данных серии Redis

Механизм сохранения Redis серии Redis

Репликация Master-Slave серии Redis

Режим Sentinel серии Redis

Почему настойчивость

Если при повторном обращении к Redis данные Redis окажутся пустыми, произойдет проникновение в кеш. Что еще более важно, поскольку данные Redis пусты, нет ключа, к которому клиент хочет получить доступ, что приведет к мгновенному попаданию большого количества запросов в базу данных, вызывая лавины кеша (небольшое количество ключей — это проникновение, большое номер ключа Лавина). В это время база данных может зависнуть. И нет никакой гарантии, что redis не упадет, поэтому необходимо быстро восстанавливать содержимое в redis, когда redis не работает. Поэтому нужно сделать настойчивость. Постоянство предназначено для восстановления данных, а не для их хранения.

RDB

RDB (Redis DataBase) — это метод хранения Redis по умолчанию, а метод RDB дополняется созданием моментальных снимков.

Как запустить снимок

Соблюдайте настраиваемые правила моментальных снимков

• save 900 1 # Указывает, что по крайней мере 1 ключ был изменен в течение 15 минут (900 секунд) для создания моментального снимка.

• save 300 10 # Указывает, что по крайней мере 10 ключей были изменены в течение 5 минут (300 секунд) для создания моментального снимка.

• save 60 10000 # Указывает, что в течение 1 минуты было изменено не менее 10 000 ключей, затем быстро

N秒内数据集至少有M个改动”这一条件被满足时，自动保存一次数据集。

Выполните команду сохранения или bgsave

Выполните команду save или bgsave, чтобы сгенерировать файл dump.rdb.Каждый раз при выполнении команды вся память Redis будет создаваться в новый файл rdb, а исходный файл моментального снимка rdb перезаписывается.

Сравните save и bgsave:

Заказ	save	bgsave
Тип ввода-вывода	Синхронизировать	асинхронный
Блокировать ли другие команды Redis	да	Нет (будет короткий блок при порождении дочернего процесса для вызова функции fork)
сложность	O(n)	O(n)
преимущество	Не потребляет дополнительную память	Не блокировать клиентские команды
недостаток	Блокировать клиентские команды	Нужно разветвить дочерний процесс, потребляющий память

配置自动生成rdb文件后台使用的是bgsave方式。

Выполнить команду сброса

flushall

Перед очисткой Redis сохраните текущий снимок Redis.

Выполнение операции репликации master-slave (в первый раз)

Файл rdb должен быть сгенерирован для первой репликации master-slave, и текущий моментальный снимок Redis будет сохранен.

Процесс выполнения РБД

• Анализ процесса

  • 1. Родительский процесс Redis сначала определяет, выполняет ли он в данный момент дочерний процесс сохранения или bgsave/bgrewriteaof (команда перезаписи файла aof).Если он выполняется, команда bgsave возвращается напрямую.
  • 2. Родительский процесс выполняет операцию fork (вызов функции операционной системы для копирования основного процесса) для создания дочернего процесса, во время которого родительский процесс блокируется, и Redis не может выполнять какие-либо команды от клиента.
  • 3. После разветвления родительского процесса команда bgsave возвращает сообщение «Начато сохранение в фоновом режиме» и больше не блокирует родительский процесс и может реагировать на другие команды.
  • 4. Дочерний процесс создает файл RDB, генерирует временный файл снимка на основе снимка памяти родительского процесса и атомарно заменяет исходный файл после завершения. (РБД всегда полная)
  • 5. Дочерний процесс отправляет родительскому процессу сигнал о завершении, и родительский процесс обновляет статистику.
  • 6. После того, как родительский процесс разветвит дочерний процесс, продолжайте работу.

Структура файла RDB

• 1. 5 байтов заголовка фиксируются как строка «REDIS».
• 2. 4-байтовый номер версии «RDB» (не номер версии Redis), в настоящее время 9 и 0009 после заполнения.
• 3. Вспомогательные поля, в виде ключ-значение
• 4. Сохраните номер базы данных
• 5. Размер словаря
• 6. Просроченный ключ
• 7. Основные данные, хранящиеся в виде ключ-значение
• 8. Знак окончания
• 9, контрольная сумма, чтобы увидеть, поврежден ли файл или был ли он изменен

Преимущества и недостатки RDB

преимущество

• RDB представляет собой сжатый двоичный файл, занимающий мало места и легко передаваемый (ведомому)

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

недостаток

• Целостность данных не гарантируется, и все данные, измененные с момента создания последнего снимка, будут потеряны.

AOF

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

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

Реализация постоянства AOF

Настроить redis.conf

# 可以通过修改redis.conf配置文件中的appendonly参数开启 
appendonly yes

# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。 
dir ./

# 默认的文件名是appendonly.aof，可以通过appendfilename参数修改 
appendfilename appendonly.aof

Принцип АОФ

В файле AOF хранятся команды redis.Весь процесс синхронизации команд с файлами AOF можно разделить на три этапа:

• Распространение команды: Redis отправляет выполненную команду, параметры команды, количество параметров команды и другую информацию в программу AOF.

• Добавление кэша: программа AOF преобразует команду в формат сетевого протокола связи в соответствии с полученными данными команды, а затем добавляет содержимое протокола в кэш AOF сервера.

• Запись и сохранение файла: содержимое кэша AOF записывается в конец файла AOF.Если заданные условия сохранения AOF соблюдены, будет вызвана функция fsync или функция fdatasync для фактического сохранения записанного содержимого на диск. .

распространение команды

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

кэш добавить

После того, как команда будет передана программе AOF, программа преобразует команду из строкового объекта обратно в исходный текст протокола в соответствии с командой и параметрами команды. После создания текста протокола он добавляется в конец aof_buf в структуре redis.h/redisServer.

Структура redisServer поддерживает состояние сервера Redis, а поле aof_buf содержит весь текст протокола (RESP), ожидающий записи в файл AOF.

Запись и сохранение файла

Функция aof.c/flushAppendOnlyFile вызывается всякий раз, когда выполняется рутинная задача сервера или обработчик события.Эта функция выполняет две функции:

• ЗАПИСЬ: Запись буфера из aof_buf в файл AOF в соответствии с условием.

• СОХРАНИТЬ: вызовите функцию fsync или fdatasync, чтобы сохранить файл AOF на диск в соответствии с условием.

Режим сохранения AOF

В настоящее время Redis поддерживает три режима сохранения AOF:

• AOF_FSYNC_NO : не сохранять.

• AOF_FSYNC_EVERYSEC: сохранять каждую секунду. (По умолчанию)

• AOF_FSYNC_ALWAYS: сохранять каждый раз при выполнении команды. (Не рекомендуется)

AOF_FSYNC_NO

Никогда не используйте fsync, оставьте данные операционной системе для обработки. Более быстрый и менее безопасный вариант.

SAVE будет выполняться только в любой из следующих ситуаций:

• Редис закрыт

• Функция AOF отключена

• Кэш записи системы очищен (возможно, кеш заполнен или выполняется периодическая операция сохранения)

Операция SAVE в этих трех случаях приведет к блокировке основного процесса Redis.

AOF_FSYNC_EVERYSEC

В принципе, SAVE выполняется каждую секунду, потому что операция SAVE вызывается фоновым подпотоком (форком), поэтому она не приведет к блокировке основного процесса сервера и потеряет только 1 секунду данных в случае сбоя. .

AOF_FSYNC_ALWAYS

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

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

Влияние режима сохранения AOF на производительность и безопасность

Сравнение трех режимов

AOF переписать

Процесс изменения данных записи AOF становится все больше и больше, и его необходимо переписать для «похудения».

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

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

Так называемая «перезапись» на самом деле многозначное слово, на самом деле перезапись AOF не требует какой-либо записи и чтения исходного файла AOF, она направлена ​​на текущее значение ключа в базе данных.

Например

set s1 11
set s1 22
set s1 33

lpush list1 1 2 3
lpush list1 4 5 6

После перезаписи AOF

set s1 33

lpush list1 1 2 3 4 5 6

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

• 1. Во время перезаписи AOF дочернего процесса основной процесс может продолжать обрабатывать запрос команды.

• 2. Дочерний процесс имеет копию данных основного процесса.Использование дочернего процесса вместо потока может обеспечить безопасность данных без блокировки.

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

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

Анализ процесса перезаписи

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

Когда дочерний процесс выполняет перезапись AOF, основной процесс должен выполнить следующие три задачи:

• Запросы команд обработки.
• Добавьте команды записи в существующий файл AOF.
• Добавить команды записи в кэш перезаписи AOF

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

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

• Запишите содержимое кэша перезаписи AOF в новый файл AOF.
• Переименуйте новый файл AOF, чтобы перезаписать исходный файл AOF.

Команды в процессе перезаписи +AOF в базе данных Redis ------->Новый файл AOF---->Перезаписать старый Когда шаг 1 завершен, существующий файл AOF, новый файл AOF и база данных три. Статус точно так же.

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

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

Метод триггера перезаписи AOF

• 1. Настройте триггер

#表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准
auto-aof-rewrite-percentage 100

#限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化
auto-aof-rewrite-min-size 64mb

• 2. Выполните команду bgrewriteaof

127.0.0.1:6379>bgrewriteaof‘
Backgroundappendonlyfilerewritingstarted

Резюме перезаписи AOF

Гибридная настойчивость

У RDB и AOF есть свои преимущества и недостатки, и Redis 4.0 начал поддерживать смешанную персистентность rdb и aof.

Если гибридное сохранение включено, содержимое rdb будет записано непосредственно в начало файла aof при выполнении aofrewrite.

Головка RDB + тело AOF ----> appendonly.aof

Включить гибридное сохранение

aof-use-rdb-preambleyes

Загрузка файла AOF и восстановление данных

Если включена гибридная сохраняемость, то при перезаписывании AOF данные памяти больше не преобразуются в команды RESP и не записывается файл AOF, а выполняется обработка моментального снимка RDB в памяти до момента перезаписи, а также содержимое моментального снимка RDB и команды добавочного AOF. чтобы изменить данные памяти, существуют вместе, и все они записываются в новый файл AOF. Новый файл сначала не называется appendonly.aof, и он будет переименован после того, как новый файл AOF будет перезаписан, перезаписывая исходный файл AOF. для завершения замены старых и новых файлов AOF.

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

• 1. Создайте поддельный клиент без подключения к сети

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

• 2. Проанализируйте и прочитайте команду записи из файла AOF.

• 3. Используйте псевдоклиент для выполнения команды чтения и записи.

• 4. Продолжайте выполнять шаги 2 и 3, пока не будут обработаны все команды записи в файл AOF.

Стратегия резервного копирования данных Redis

• 1. Напишите сценарий расписания crontab, копируйте резервную копию rdb или aof в каталог каждый час и сохраняйте резервную копию только за последние 48 часов.

• 2. Сохраняйте резервную копию данных за текущий день в каталоге каждый день, вы можете сохранить резервную копию за последний месяц

• 3. Каждый раз, когда вы копируете резервную копию, удаляйте старую резервную копию.

• 4. Копируйте резервную копию с текущей машины на другие машины каждую ночь, чтобы предотвратить повреждение машины.

Сравнение RDB и AOF

• 1. RDB хранит моментальные снимки данных в определенное время, используя хранилище с бинарным сжатием, команды работы с хранилищем AOF, используя текстовое хранилище (смешанный)

• 2. Высокая производительность RDB и низкая производительность AOF

• 3. RDB потеряет все данные, измененные после последнего моментального снимка в состоянии триггера конфигурации.Если AOF настроен на сохранение один раз в секунду, данные будут потеряны на срок до 2 секунд.

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