Вы используете Redis каждый день, знаете ли вы, какие существуют решения для сохраняемости?

предисловие

• Статья была впервые опубликована в общедоступной учетной записи WeChat [Code Ape Technology Column]: [Используйте Redis каждый день, знаете ли вы, какие существуют решения для сохраняемости? ] (Https://mp.weixin.qq.com/s?__biz=MzI0ODYzMzIwOA==&mid=2247484106&idx=1&sn=f2dc239478b6481e52e9bbe94687d662&chksm=e99c80dddeeb09cbc241f4e0fefab7ffee7639338de7eb8809455ec91f42ab961f96e16a9c75&scene=126&sessionid=1587346810&key=087e4453ab2c10b91659b80845b2b74c5fb001ce66f3d4e0ddb18cb8bbb391009c4518efb34e1fde3a28f36fd6605ce0fa5b5a2f2ca2e399d976d46d28626c1bfeb90a361de7cc442db9da177701e750&ascene=1&uin=MTA3MjI0MTk2&devicetype=Windows+10&version=62080079&lang=zh_CN&exportkey=AarKwCVq4htSp1dFaUsiQC4 %3D&pass_ticket=vpBJqr5QTpXblOduck%2BE8iwsQJsQiFnM5ZRMsNTec0M%3D)
• Redis стал основной базой данных в памяти, но большинство людей только на стадии ее использования.Вы действительно понимаете внутренний принцип работы Redis?
• В сегодняшней статье будут представлены два решения для сохраняемости Redis. В статье будут представлены следующие пять аспектов:

  1. **Что такое RDB и как RDB обеспечивает постоянство? **
  2. **Что такое AOF и как AOF обеспечивает постоянство? **
  3. **Разница между AOF и RDB. **
  4. **Как перезагрузиться для восстановления данных? **
  5. **Проблемы с постоянной производительностью и их решения**

RDB

• Постоянство RDB — это процесс создания моментального снимка текущих данных процесса и их сохранения на жесткий диск.Запуск процесса сохранения RDB делится на запуск вручную и автоматический запуск.
• После того, как RDB будет завершена, файл будет автоматически сгенерирован и сохранен в указанном каталоге, настроенном `dir`.Имя файла указывается `dbfileName`.
• По умолчанию Redis будет использовать алгоритм LZF для сжатия сгенерированного файла RDB.Сжатый файл намного меньше размера памяти и включен по умолчанию.

Ручной триггер

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

автоматический триггер

• Помимо ручного запуска RDB, на сервере Redis есть несколько сценариев, которые могут автоматически запускать RDB:

  1. Запускается автоматически на основе наших правил конфигурации `save m n`.
  2. Если подчиненный узел выполняет операцию полного копирования, главный узел автоматически выполняет bgsave для создания файла RDB и отправки его подчиненному узлу.
  3. Когда для перезагрузки Redis выполняется команда `debug reload`, операция сохранения также запускается автоматически.
  4. По умолчанию, когда выполняется команда выключения, если функция сохранения AOF не включена, автоматически выполняется `bgsave`.

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

• Основным методом RDB является bgsave Давайте посмотрим на процесс выполнения RDB на следующем рисунке: 
• На приведенном выше рисунке отчетливо виден процесс выполнения RDB, а именно:

  1. После выполнения команды bgsave она сначала определит, есть ли дочерний процесс AOF или RDB, и если да, то вернется напрямую.
  2. Операция fork родительского процесса создает дочерний процесс, и родительский процесс будет заблокирован во время операции fork.
  3. После завершения разветвления дочерний процесс начинает генерировать временный файл моментального снимка на основе памяти родительского процесса и заменяет исходный файл RDB после завершения. Выполните команду `lastsave`, чтобы просмотреть последнее время RDB.
  4. После завершения дочернего процесса родительскому процессу отправляется сигнал, и родительский процесс обновляет статистику.

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

• RDB — это компактно сжатый двоичный файл, представляющий моментальный снимок данных Redis в определенный момент времени. Он очень подходит для резервного копирования, полной репликации и других сценариев. Например, выполняйте резервное копирование bgsave каждые 6 часов и копируйте файл RDB на удаленный компьютер или в файловую систему для аварийного восстановления.
• Redis загружает «RDB» для восстановления данных намного быстрее, чем «AOF».

Недостатки РБД

• Невозможно добиться «постоянства в реальном времени»/«постоянства второго уровня» для данных RDB. Поскольку bgsave необходимо выполнять операцию ветвления для создания дочернего процесса каждый раз, когда он запускается, это тяжеловесная операция, и стоимость ее частого выполнения слишком высока.
• Файлы RDB сохраняются в определенном двоичном формате. В ходе эволюции версии Redis появились версии RDB в нескольких форматах. Существует проблема, заключающаяся в том, что старая версия службы Redis не может быть совместима с новой версией формата RDB.

AOF

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

Как включить Aof

• Для включения функции AOF требуются настройки: «Appendonly Yes», ​​не открыто по умолчанию. Имя файла AOF через настройку конфигурации «appendfilename», имя файла по умолчанию — «Appendonly.aof». Путь сохранения согласуется с сохраняемостью RDB и задается конфигурацией `Dir`.

Общий процесс выполнения AOF

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

написать команду

• Содержимое, записанное командой AOF, находится непосредственно в формате текстового протокола. Например, команда set hello world добавит в буфер AOF следующий текст:

  *3\r\n3\r\nset\r\n5\r\nhello\r\n$5\r\nworld\r\n

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

синхронизация файлов

• Redis предоставляет различные стратегии файловой синхронизации буфера AOF, управляемые параметром `appendfsync`, а именно:

  • При настройке «всегда» файл AOF должен синхронизироваться для каждой записи.На обычном жестком диске SATA Redis может поддерживать только около нескольких сотен операций записи в секунду, что явно противоречит высокопроизводительным функциям Redis и не рекомендуется.
  • Настроен как «нет», потому что операционная система синхронизирует файлы AOF каждый раз, когда цикл не поддается контролю, и будет увеличивать объем данных на синхронизируемом жестком диске каждый раз, хотя производительность улучшается, безопасность данных не может быть гарантирована.
  • Конфигурация «каждая секунда» (конфигурация по умолчанию) является **рекомендуемой стратегией синхронизации** и конфигурацией по умолчанию, принимая во внимание как производительность, так и безопасность данных. Теоретически в случае внезапного простоя системы теряется всего 1 секунда данных (конечно, это не очень точно).

механизм перезаписи файлов

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

  • Ручной запуск выполняется напрямую с помощью команды bgrewriteaof.
  • Определите время автоматического запуска в соответствии с параметрами auto-aof-rewrite-min-size и auto-aof-rewrite-percentage.
• `auto-aof-rewrite-min-size`: указывает минимальный размер файла при запуске перезаписи AOF, по умолчанию 64 МБ.
• `auto-aof-rewrite-percentage`: представляет отношение текущего файлового пространства AOF (`aof_current_size`) к файловому пространству AOF после последней перезаписи (`aof_base_size`).
• Время автоматического запуска эквивалентно **aof_current_size>auto-aof-rewrite-minsize&&(aof_current_size-aof_base_size) /aof_base_size>=auto-aof-rewritepercentage**. Где `aof_current_size` и `aof_base_size` можно посмотреть в статистике `info Persistence`.
• **Тогда почему файл AOF после перезаписи файла становится меньше? ** Причин несколько:

  1. Данные в процессе, время ожидания которых истекло, не будут снова записываться в файл AOF.
  2. Старые файлы AOF содержат недопустимые команды, такие как «del key1», «hdel key2» и т. д. Перезапись напрямую использует генерацию данных в процессе, так что новый файл AOF сохраняет только окончательные данные команды записи.
  3. Несколько команд записи можно объединить в одну, например: `lpush list a`, `lpush list b`, `lpush listc` можно преобразовать в: `lpush list a b c`. Для предотвращения переполнения клиентского буфера одной командой из-за чрезмерного размера команды операции `list`, `set`, `hash`, `zset` и другие типы разделены на несколько частей с 64 элементами. как граница.
• Вводит ряд знаний о перезаписи файлов. Давайте посмотрим, как перезапись файлов выполняется внутри Redis, как показано ниже: 
• Прочитав картинку выше, я имею общее представление о процессе перезаписи файлов.Для процесса перезаписи добавлю следующее:

  1. Во время перезаписи основной поток не блокируется, а выполняет другие рабочие команды и по-прежнему записывает данные в старый файл AOF, что может обеспечить окончательную целостность резервной копии.Если перезапись данных не удалась, он также может гарантировать, что данные не будут потеряны.
  2. Чтобы записать ответную информацию о записи во время перезаписи в новый файл, буфер также зарезервирован для дочернего процесса, чтобы предотвратить потерю данных вновь записанным файлом.
  3. Перезапись заключается в непосредственном создании соответствующей команды из данных в текущей памяти и не требует чтения старого файла AOF для анализа и объединения команд.
  4. «Текстовый протокол», непосредственно принятый файлом AOF, в основном предназначен для хорошей совместимости, удобного добавления и высокой читабельности, что может быть рассмотрено для модификации и исправления.
  5. Будь то `RDB` или `AOF`, он сначала записывается во временный файл, а затем `rename` завершает замену файла.

Преимущества АОФ

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

Недостатки АОФ

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

Разница между AOF и RDB

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

перезагрузить загрузку

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

Проблемы с производительностью и решения

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

  1. Расставьте приоритеты в использовании физических машин или технологий виртуализации, которые эффективно поддерживают операции разветвления.
  2. Управляет максимальной доступной памятью экземпляра Redis. Время разветвления пропорционально объему памяти. Рекомендуется контролировать объем памяти каждого экземпляра Redis в пределах 10 ГБ.
  3. Разумно настройте стратегию выделения памяти Linux, чтобы избежать сбоя ветки из-за нехватки физической памяти.
  4. Уменьшите частоту операций форка, например, умеренно ослабьте время автоматического срабатывания AOF, избегайте ненужного полного копирования и т. д.

Суммировать

• В этой статье представлены две разные стратегии обеспечения устойчивости Redis. Большую часть контента должен освоить персонал, занимающийся эксплуатацией и техническим обслуживанием. Конечно, как обслуживающий персонал, они также должны понимать. В конце концов, все небольшие компании занимаются полной стек одним человеком, ха-ха.
• ** Если вы считаете, что текст Чена хорош и имеет что-то полезное, пожалуйста, подпишитесь и поделитесь волной, ваше внимание будет самой большой мотивацией для письма Чена, спасибо за вашу поддержку! ! ! **

•