Redis предоставляет два способа сохранения:

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

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

постоянная конфигурация
Как работают постоянства RDB и AOF
Как восстановить данные из хранилища
О производительности и практических советах

постоянная конфигурация

Чтобы использовать функцию постоянства, нам нужно сначала знать, как включить функцию постоянства.

Конфигурация постоянства RDB

# 时间策略
save 900 1
save 300 10
save 60 10000

# 文件名称
dbfilename dump.rdb

# 文件保存路径
dir /home/work/app/redis/data/

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩
rdbcompression yes

# 导入时是否检查
rdbchecksum yes

Конфигурация на самом деле очень проста, вот что означает стратегия постоянного времени.

save 900 1Указывает, что при наличии одной команды записи в течение 900 с будет запущен моментальный снимок, который можно понимать как резервное копирование.
save 300 10Указывает, что в течение 300 с было произведено 10 операций записи и создан моментальный снимок.

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

stop-writes-on-bgsave-error yesЭта конфигурация также очень важна: при сбое процесса резервного копирования основной процесс перестает принимать новые операции записи, чтобы защитить постоянные проблемы с согласованностью данных.Если в вашем бизнесе есть полноценная система мониторинга, вы можете запретить эту настройку.В противном случае включите его.

Конфигурация для сжатияrdbcompression yes, его не обязательно включать.В конце концов, Redis сам по себе является сервером, интенсивно использующим ЦП.Включение сжатия приведет к большему потреблению ЦП.По сравнению со стоимостью жесткого диска ЦП более ценен.

Конечно, если вы хотите отключить конфигурацию RDB, это тоже очень просто, просто напишите в последней строке сохранения:save ""

Конфигурация АОФ

# 是否开启aof
appendonly yes

# 文件名称
appendfilename "appendonly.aof"

# 同步方式
appendfsync everysec

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof时如果有错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

Или сосредоточьтесь на объяснении некоторых ключевых конфигураций:

appendfsync everysecНа самом деле он имеет три режима:

всегда: немедленно синхронизируйте каждую команду записи в aof, очень медленно, но очень безопасно
Everysec: синхронизировать каждую секунду, что является компромиссом.
нет: redis не обрабатывает его и передает ОС, что очень быстро, но и наименее безопасно

Обычно используетсяeverysecКонфигурация, которая может учитывать скорость и безопасность и терять до 1 с данных.

aof-load-truncated yesЕсли эта конфигурация включена, если во время загрузки будет обнаружено, что хвост aof неверен, на клиент будет записан журнал, но выполнение будет продолжено.no, он останавливается при обнаружении ошибки и должен быть исправлен перед повторной загрузкой.

Принцип работы

Что касается основной части, мы в основном рассматриваем, как RDB и AOF завершают персистентность и каков их процесс.

Прежде чем представить принцип, давайте поговорим о механизме задания времени внутри Redis.Частота выполнения задания времени может быть передана в конфигурационном файле.hz 10Установить (такая конфигурация означает, что она выполняется 10 раз за 1с, то есть запланированная задача запускается каждые 100мс). Это значение может быть установлено на:500, но не рекомендуется превышать:100, потому что чем больше значение, тем чаще и выше будет частота выполнения, что приведет к большему потреблению ЦП, что повлияет на производительность чтения и записи основного процесса.

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

Принцип РБД

Существует два типа триггеров для сохраняемости RDB в Redis: запуск вручную и запуск Redis по времени.

Для сохранения в режиме RDB можно использовать ручной запуск:

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

Сценарии автоматического срабатывания в основном включают следующее:

Согласно нашемуsave m nПравила конфигурации запускаются автоматически;
Когда подчиненный узел полностью реплицирован, главный узел отправляет файл rdb подчиненному узлу для завершения операции копирования, и главный узел инициируетbgsave;
воплощать в жизньdebug reloadВремя;
воплощать в жизньshutdown, если aof не включен, он также сработает.

так какsaveВ основном он не будет использоваться, давайте сосредоточимся на немbgsaveКак эта команда завершает сохранение RDB.

Обратите внимание, чтоforkОперация будет заблокирована, что приведет к снижению производительности чтения и записи Redis. Мы можем контролировать максимальный объем памяти одного экземпляра Redis, чтобы свести к минимуму потребление событий Redis во время разветвления. А частота автоматического срабатывания, упомянутая выше, уменьшает количество вилок, или используйте ручное срабатывание для полного сохранения в соответствии с собственным механизмом.

Принцип АОФ

Весь процесс AOF можно условно разделить на два шага, один из которых — написание команд в реальном времени (если онappendfsync everysecконфигурации будет потеря 1с), второй шаг - переписать файл aof.

Основной процесс инкрементного добавления к файлу: команда write = "добавить к aof_buf = "синхронизировать с диском aof. Итак, почему вы хотите сначала записать buf и синхронизировать с диском? Если он записывается на диск в режиме реального времени, это приведет к очень высокому дисковому вводу-выводу и повлияет на общую производительность.

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

Ручной триггер: bgrewriteaof,автоматический триггерОн запускается в соответствии с правилами конфигурации.Конечно, общее время автоматического срабатывания также связано с частотой запланированных задач Redis.

Давайте посмотрим на блок-схему перезаписи:

К приведенному выше рисунку следует добавить четыре ключевых момента:

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

Не может быть RDB или AOF сначала записывается во временный файл, а потом черезrenameЗавершите замену файла.

Восстановление данных из хранилища

После завершения резервного копирования и сохранения данных, как мы можем восстановить данные из этих постоянных файлов? Если на сервере есть и RDB-файлы, и AOF-файлы, кого следует загружать?

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

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

Производительность и практика

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

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

Что нам делать онлайн? Предлагаю немного собственного практического опыта.

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

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

публика:dayuTalk