Супер подробно! Подробное объяснение устойчивости Redis
Супер подробно! Подробное объяснение устойчивости Redis

Количество слов: 8059 слов. Чтение занимает около 25 минут.

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

Представьте себе, что когда ваше приложение внезапно отключается или сервер выходит из строя, при отсутствии сохранения эти ценные данные могут мгновенно исчезнуть. Так кто же будет использовать такую ​​базу данных?

Таким образом, понимание принципа сохранения Redis имеет решающее значение для Redis для обеспечения целостности данных, поэтому вопрос о сохранении Redis часто поднимается на собеседованиях.

В этой статье мы вместе с вами узнаем о механизме персистентности Redis.

Метод сохранения Redis

RedisЕсть два способа сохраниться:RDB(Redis DataBase)иAOF(Append Only File)

RDB: файл RDB представляет собой сжатый двоичный файл.

AOF: AOF записывает каждую команду записи, выполняемую Redis, в виде добавления.

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

Далее я представлю принципы реализации RDB и AOF соответственно.

RDB

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

Файл моментального снимка — это двоичный файл, содержащий все данные Redis на определенный момент времени.

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

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

Как показано на рисунке ниже, если сервер выйдет из строя в момент T2, данные на ключах k3 и k4 могут быть потеряны.

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

Существует два способа активировать сохранение RDB: автоматический и ручной.

Руководство: пройти вручную save команда или bgsave Заказ продолжается.

Автоматический: автоматический режим задается в файле конфигурации и автоматически запускается при выполнении условий.

Ручной режим

  • save:save Команда заблокирует Redis серверпроцесс,Пока файл RDB не будет создан,существоватьсерверпроцесспериод блокировки,Сервер не может обрабатывать какие-либо командные запросы.
  • bgsave:bgsave командное совещание fork Дочерний процесс (обратите внимание на дочерний процесс, а не на дочерний поток) генерирует документ-снимок в фоновом режиме, не блокируя его. Redis сервер, серверный процесс (родительский процесс) может продолжать обрабатывать запросы команд.

Во время выполнения команды bgsave команды save и bgsave, отправленные клиентом, будут отклонены. Это необходимо для предотвращения конкуренции между родительским и дочерним процессами.

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

автоматический режимдаотносится к прохождениюсерверфайл конфигурации save вариант, давай Redis Автоматически выполнять время от времени bgsave , по существу через bgsave команду для реализации.

Опция сохранения файла конфигурации позволяет настроить несколько условий. При выполнении любого из условий будет срабатывать bgsave.

То есть: когда выполняется условие «набор данных имеет не менее M изменений в течение N секунд».

Например, если мы предоставим серверу следующую конфигурацию:

Язык кода:javascript
копировать
save 900 1
save 300 10
save 60 10000

Затем, если выполнено любое из следующих трех условий, команда bgsave будет выполнена:

  • серверсуществовать 900 секунд внутри, на базе данные проведены как минимум 1 раз Исправлять.
  • серверсуществовать 300 секунд внутри, на базе данные проведены как минимум 10 раз Исправлять.
  • серверсуществовать 60 секунд внутри, на базе данные проведены как минимум 10000 раз Исправлять.

Если пользователь не устанавливает параметр сохранения активно, сервер установит для параметра сохранения условия по умолчанию:

Язык кода:javascript
копировать
save 900 1
save 300 10
save 60 0000

Зная вышесказанное, нам еще нужно решить две задачи:

  1. сохранить конфигурацию опции,По чему оценивают Redisда?
  2. Redis Когда пора судить?

Вопрос 1. Как Redis определяет конфигурацию параметров сохранения?

Сервер Redis внутренне поддерживает счетчик:грязный и метку времени:lastsave.

  • грязный счетчик:грязный счетчик записывает расстояние от последнего успешного выполнения save команда или ВОЗ bgsave После заказа сервер против базы СТАТУС данных (все базы на сервере Сколько раз была изменена команда (включая запись, удаление, обновление и т. д.) и сколько раз была изменена база данных команды данных,грязный Значение счетчика увеличивается на эту сумму.
  • последнее сохранение временной метки:последнее сохранение временной метки записывает последнее успешное выполнение сервера save команда или ВОЗ bgsave время команды.

Например, в определенный момент значения счетчика загрязнений и метки времени последнего сохранения следующие:

Язык кода:javascript
копировать
dirty:200
lastsave:1703952000000

Указывает, что сервер внес в общей сложности 200 изменений в состояние базы данных с момента последнего сохранения (31 декабря 2023 г., 00:00:00).

Таким образом оценивается, выполнены ли условия.

Вопрос 2. Когда Redis пора вынести решение?

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

serverCron будет проверять все условия сохранения и выполнять команду bgsave, если какое-либо условие соблюдается.

После выполнения bgsave Redis сбросит значениягрязного и последнего сохранения. грязный сбрасывается в 0, а последнее сохранение обновляется до времени последнего сохранения.

функция вилки и копирование при записи

В Redis команда bgsave использует функцию fork для создания дочернего процесса для создания RDB, позволяя родительскому процессу получать и обрабатывать команды записи.

Так как же Redis обрабатывает запросы на запись и одновременно генерирует файлы RDB?

Redis используя операционную систему технология копирования при записи COW(Copy On Write) Чтобы добиться сохранения моментального снимка.

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

Примечание: JDK CopyOnWriteArrayList и CopyOnWriteArraySet Контейнеры также используются. копирования при записи。

мы можем использовать Под Linux man fork Команда для проверки fork Функциональная документация.

Перевод следующий:

существоватьLinuxВниз,fork() реализован с использованием страницы, написанной в копировать,Таким образом, его единственная стоимость — это дакопирование таблиц страниц родительского процесса и время, необходимое для создания уникальной структуры задач для дочернего процесса и памяти.

Проще говоря, это fork()Функция будеткопироватьотецпроцессизадресное пространство для субпроцесссередина,копироватьиздауказатель,и Нетдаданные,Так что это очень быстро.

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

Пока это не произойдет при написании,Система фактически скопирует новую область памяти.,Операции чтения и операции записи существуют в разных областях памяти.,Исходный ресурс, видимый подпроцессом, остается неизменным.,От и добиться изоляции процесса отца и сына.

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

Принципиальная схема выглядит следующим образом:

Используя fork Функция и механизм копирования времени написания, Redis может быть эффективно выполнено RDB операции сохранения и не будут Redis Сильно страдает производительность во время работы.

В то же время этот подход также обеспечивает простой и эффективный механизм защиты Redis данныепоследовательностьинадежность。

Однако в отношении функции fork следует отметить два момента:

  • fork Этот процесс блокируется и разветвляется Никакой блокировки после завершения.
  • Когда набор данных относительно велик,Процесс форка занимает очень много времени,Процесс может занять несколько секунд,Основной сервер может зависнуть на длительное время из-за большого объема данных.,Сделайте службу Redis недоступной.

Конфигурация, связанная с RDB

Ниже приведены некоторые конфигурации параметров, связанные с RDB:

  • save:обозначение RDB Условия для операций сохранения. когда Redis данные изменяются, и по истечении указанного времени (секунд) и количества изменений (изменений) Redis будет выполнено автоматически RDB действовать. Например, сохранить 3600 10000 Выразите, если Redis данныесуществовать произошло в течение часа минимум 10000 раз модификация, то Redis будет выполнен один раз RDB действовать.
  • stop-writes-on-bgsave-error:обозначениесуществовать RDB Если в процессе сохранения возникает ошибка да Нет, прекратить запись, если установлено. на да, когда Redis в исполнении RDB Если во время работы возникает ошибка, Redis перестанет принимать операции записи, если установлено значение; no,Redis Продолжаем принимать записи для действий.
  • rdbcompression:обозначениеда Нет права RDB Файл сжат. Если установлено значение yes,Redis будет создан RDB Сжать файл, чтобы уменьшить занимаемое место на диске, если этот параметр установлен; на no,Redis не будет генерировать RDB Файл сжат.
  • rdbchecksum:обозначениеда Нет права RDB Файл проверен и рассчитан. Если установлен на да, экономия RDB файл, Редис Рассчитаю один CRC64 Отметьте è и добавьте его в RDB Конец файла при загрузке; RDB файл, Редис Файлы будут проверены и проверены, чтобы убедиться, что они не были повреждены или подделаны.
  • replica-serve-stale-data:этотда Redis 4.0 В добавлен новый элемент конфигурации, который используется для указания, будет ли узел существовать продолжать отправлять сообщения клиенту после его отключения от главного узла. Когда установлено на yes Когда существующий узел отсоединяется от главного узла, узел будет продолжать предоставлять старые данные клиенту до тех пор, пока главный узел не будет повторно подключен и полностью новые данные не будут синхронизированы при установке; на no , копирующий узел немедленно прекратит предоставлять данные клиенту и будет ждать, пока главный узел повторно подключится и синхронизирует данные. На что следует обратить внимание при replica-serve-stale-data установлен на yes час,Могут быть некоторые проблемы несоответствия в существовании.,Поэтому рекомендуется использовать его только в определенных сценариях.
  • repl-diskless-sync:этотда Redis 2.8 Элемент конфигурации, представленный в разделе , используемый для указания, следует ли использовать бездисковую синхронизацию, когда узел существует, выполняет первую полную синхронизацию (то есть получает все данные от главного узла). Когда установлено на yes При копировании узел напрямую получает данные главного узла через сеть и не сохраняет данные на локальном диске при его установке; на no Когда , копирующий узел сначала сохранит данные главного узла на локальном диске, а затем синхронизируется. Метод бездисковой синхронизации позволяет избежать диска. IO Эта операция повлияет на производительность системы, но также увеличит нагрузку на сеть и использование памяти.

AOF

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

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

Интерпретация файла AOF

Простой пример файла AOF выглядит следующим образом:

В этом файле показаны две команды:

Язык кода:javascript
копировать
select 0
set k1 hello

в:

  • *: указывает количество параметров,За ним следует длина и значение параметра.
  • Знак $: указывает длину параметра, за которым следует значение параметра.

Все команды, сохраненные в файле AOF, имеют один и тот же формат, то есть, начиная с *, указывается количество параметров, начиная с $, указывается длина параметра, за которым следует значение параметра.

У AOF есть лучшее преимущество: он может восстанавливать ошибки в работе.

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

Запись и синхронизация AOF

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

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

и AOF Кэш синхронизируется с AOF файл, процесс, называемый flushAppendonlyFile функция завершена.

и flushAppendOnlyFile Поведение функции определяется файлом конфигурации сервера. appendfsync Этот параметр имеет следующие три параметра:

  • always:пишите каждый раз Заказ,Все синхронизировано с документом AOF.,да Самый безопасный вариант.
  • everysec:Синхронно пишет раз в секунду в AOF документ,существовать обеспечивает баланс между производительностью и безопасностью.
  • no:Нет Активное письмо AOF документ, операционная система сама решает, когда выполнять синхронизацию.

По умолчанию Редис appendfsync Параметры everysec . Если вам нужно улучшить постоянную безопасность, вы можете изменить его на always , если производительность более важна, вы можете изменить ее на no。Да На что следует обратить внимание,использовать no Это может привести к риску потери данных. Рекомендуется использовать с осторожностью, если позволяет сценарий приложения.

Переписать АОФ

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

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

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

Редис Переписать Механизм АОФ относится к общему AOF Избыточные команды в файлах удалены для уменьшения AOF размер файла и улучшить производительность чтения и записи.

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

Реализация перезаписи AOF

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

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

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

Язык кода:javascript
копировать
rpush list "A"
rpush list "B"
rpush list "C"
rpush list "D"
rpush list "E"
rpush list "F"

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

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

ида Прямо с базы Прочитать ключ в данных list изценить,Затем используйте команду:rpush list "A" "B" "C" "D" "E" "F",Может напрямую заменить оригинал AOF Шесть команд в файле.

Порядок уменьшен с шести до одного, и цель перезаписи достигнута.

Механизм Редис АОФпереписать использует аналогичный подход к копированию.,Сначала сохраните снимок данных в памяти во временный файл.,затем пересечьэтот Персональныйчасдокумент,Сохраняйте только окончательное состояние Заказа.,Создайте новый файл AOF.

В частности, выполнение перезаписи AOF в Redis можно разделить на следующие этапы:

  1. Запустите процесс перезаписи AOF,Верните клиенту быстрое сообщение.
  2. Создайте временный документ и запишите пары ключ-значение из текущей базы данных во временный файл.
  3. Все команды записи преобразуются во внутренний формат представления Redis во временный файл, созданный существующим,То есть использование серии команд Redis для представления операции.,Например, используйте команду SET, чтобы присвоить значение определенному ключу.
  4. Сжимать временные файлы,Удалите лишние пробелы, новые строки и т. д.,Уменьшите размер файла.
  5. Запишите сжатое содержимое в новый файл AOF.
  6. Прекратите запись команд в старый документ AOF и замените имя нового файла AOF именем файла старого файла AOF.
  7. Завершение процесса перезаписи AOF,И отправьте клиенту информацию о завершении.

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

Вы можете выполнить эту команду в клиенте Существующий Редис, чтобы запустить процесс перезаписи AOF. Редис 2.2 Необходимо выполнить вручную BGREWRITEAOF Заказал, прибыл Redis 2.4 может запускаться автоматически Переписать АОФ。

Конкретные шаги заключаются в следующем:

Откройте инструмент командной строки redis-cli и подключитесь к службе Redis.

осуществлятьBGREWRITEAOFЗаказ,Запустите процесс перезаписи AOF.

Язык кода:javascript
копировать
$ redis-cli
127.0.0.1:6379> BGREWRITEAOF

Redis вернет идентификатор фоновой задачи, указывая, что задача перезаписи AOF запущена.

Язык кода:javascript
копировать
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started by pid 1234

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

Язык кода:javascript
копировать
127.0.0.1:6379> INFO PERSISTENCE
# Persistence
aof_enabled:1
aof_rewrite_in_progress:1
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:0
aof_current_rewrite_time_sec:14
aof_last_bgrewrite_status:ok
aof_last_write_status:ok

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

Переписать правила через конфигурацию auto-aof-rewrite-percentage и auto-aof-rewrite-min-size Управление опциями.

Проблемы, с которыми сталкивается Переписать АОФ

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

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

Как показано выше, Т1 Ключи, хранящиеся в базе данных до перезаписи, являются только k1иk2,перезапись происходит во время T2,существоватьT3часвырезатьпереписатьпериод,Клиент пишет два новых ключа: k3иk4. Момент Т4 перезаписи заканчивается.

Можно заметить, что файл AOF после момента T4 перезаписывает сервер текущей базы. Статус данных не соответствует. В новом файле AOF сохраняются только два ключа k1ик2: данные, сервербаза. данныхсейчассуществовать Но естьk1、k2、k3、k4 Четыре ключа.

Область кэша перезаписи AOF

Чтобы решить эту проблему несогласованности данных, сервер Redis устанавливает буфер перезаписи AOF.

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

Принципиальная схема выглядит следующим образом:

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

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

Затем новый файл AOF будет переименован, а существующий файл AOF будет перезаписан. На этом замена старого и нового файлов AOF завершена.

AOF переписать период,командное совещание синхронизируется с буфером AOF и перезаписать буфер AOF, Что нельзя Можно А как насчет буфера AOF вместо буфера AOF?

Думаем: может ли буфер AOF заменить буфер перезаписи AOF?

Сначала поговорим о выводах:Буферы AOF не заменяют буферы AOF.

Причина: даAOFперезаписать буферную запись да, начиная с перезаписи после всех необходимых перезаписей Заказа.,Буфер AOF может записывать только часть команды (в случае обратной записи данные в буфере AOF станут недействительными и потеряются, поэтому будет сохранена только часть Заказа),и Область кэша перезаписи АОФ нет).

Конфигурация, связанная с AOF

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

  • appendonly:Этот элемент конфигурации используется для включения или выключения AOF, по умолчанию выключен. Если включено AOF,Redis Каждый раз, когда выполняется команда записи, она добавляется к AOF Конец файла.
  • appendfilename:для установки AOF Имя файла, по умолчанию appendonly.aof。
  • appendfsync:Этот элемент конфигурациидля установки AOF из Механизм синхронизации。Есть три необязательных значения:
    • всегда: указывает, что каждая команда записи должна быть синхронизирована с диском.,Высочайшая безопасность,Да Плохая производительность。
    • Everysec: означает синхронизацию раз в секунду.,да Параметры по умолчанию,Он может не только обеспечить безопасность данных,И имеет лучшую производительность.
    • нет: указывает на отсутствие синхронизации.,ида Операционная система сама решает, когда синхронизировать данные в буфере с диском.,лучшее выступление,Да Менее безопасно。
  • auto-aof-rewrite-percentageиauto-aof-rewrite-min-size:этот Два элемента конфигурациидля установки Переписать Правила АОФ. когда AOF Размер файла превышает auto-aof-rewrite-min-size набор значений и AOF Скорость роста файлов достигает auto-aof-rewrite-percentage Когда процент определен, Redis начнется Переписать АОФдействовать. auto-aof-rewrite-percentage Значение по умолчанию — 100, auto-aof-rewrite-min-size Значение по умолчанию — 64 МБ. RedisЗапишу последний разпереписатьчасизAOFразмер,Другими словами, конфигурация по умолчанию запускается, когда размер файла AOF в два раза превышает размер после последней перезаписи, а размер файла превышает 64 МБ.
  • aof-use-rdb-preamble:Redis Новые возможности в версии 4, Гибридная устойчивость. Включить ли инкрементальную синхронизацию в течение периода перезаписи AOF. Этот элемент конфигурации существует, используется ли содержимое файла RDB в течение периода перезаписи AOF. Дано по умолчанию, если установлено наyes,Существующий заголовок файла AOF добавляет содержимое файла RDB.,Вы можете максимально уменьшить размер файла AOF.,При этом восстановить данные тоже удобно.

восстановление файла AOF

Сервер может остановиться, пока программа записывает файл AOF, что приведет к повреждению файла AOF.

происходитьэтотситуациячас,Можно использовать Redis Входит в комплект redis-check-aof программа, да AOF Чтобы восстановить файл, команда выглядит следующим образом:

Язык кода:javascript
копировать
  $ redis-check-aof –fix

Журнал пост-записи AOF

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

Например, журнал повторов в механизме хранения MySQL Innodb использует журналирование с упреждающей записью.

Однако АОФ В журнале всё наоборот, это да Журнал после записи,«После записи» означает, что Redis сначала выполняет Заказ и записывает данные в память.,Затем запишите журнал

Думая: почему это сделано именно так?

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

и Журнал после Таким образом, пусть система сначала выполнит заказ. Только если команда может быть выполнена успешно, она будет записана в журнал. В противном случае система напрямую сообщит клиенту об ошибке. Итак, Редис Одним из больших преимуществ использования ведения журнала после записи является то, что оно позволяет избежать записи неверных команд и снизить затраты на проверку синтаксиса.

Кроме того, Журнал пост-записи AOF имеет еще одно преимущество: он записывает журнал только после выполнения команды дасуществовать.,Таким образом, он не будет блокировать текущий процесс записи.

Однако ведение журнала после записи также несет в себе два потенциальных риска:

  • первый,Если вы только что завершили выполнение Заказа, машина выйдет из строя, прежде чем вы сможете записать журнал.,Что Что?этоткомандыисоответствующийизданные Есть потеряизриск。еслив это время Redis да используется как кеш, а также может использоваться как кеш из серверной базы данные перечитать в данные для восстановления, но да, если Redis да используется непосредственно как база данныхизразговаривать,в это время,Поскольку команда не протоколируется,Поэтому использовать журнал для восстановления невозможно.
  • Во-вторых,Журнал после Хотя запись позволяет избежать блокировки текущей команды, она может привести к риску блокировки следующей операции. Это потому, что АОФ Зарегистрируйтесь такжедасуществоватьосновная темасерединаосуществлятьиз,Если существуют, записывает файл журнала на диск,Давление записи на диск высокое,Это приведет к очень медленной записи на диск.,В результате последующие операции выполнить невозможно.

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

в прошлом, Redis Пользователи обычно RDB Упорство AOF Различные преимущества и недостатки настойчивости представляют собой дилемму:

  • Персистентность RDB обеспечивает быстрое хранение и восстановление данных.,Дасуществоватьсервернеисправностьчас Можно потерять многоданные。
  • Сохранение AOF может эффективно повысить безопасность данных.,Дасуществоватьмагазинивосстанавливатьсяданные Но это требует много денегвремя.

Чтобы пользователи могли одновременно воспользоваться преимуществами двух вышеупомянутых персистентностей, Redis 4.0 Запущено решение для персистентности «и пирожное, и съешь». —— RDB-AOF Гибридная устойчивость。

Такая настойчивость может быть достигнута за счет Переписать Операция АОФ создает RDB данныеи AOF данные AOF документ, в RDB Данные расположены по адресу AOF начало файла, Они хранят состояние базы данных, когда сервер начал операцию перезаписи. Что касается выполненных после выполнения операции перезаписи Redis Заказ, будет продолжать AOF формат добавлен к AOF конец файла, То есть RDB После данных.

Другими словами, да означает, что при включении Гибридной устойчивостьпосле,AOFдокументсерединаизсодержание:Первая половина содержимого RDB двоичного файла,за которыми следуют данные, добавленные AOF,АОФ расположен между двумя РБД.

Формат будет похож на следующий:

В текущей версии RDB-AOF Гибридная По умолчанию функция устойчивости отключена. Чтобы включить эту функцию, Пользователям необходимо не только включить AOF функция персистентности, Также необходимо aof-use-rdb-preamble Значение опции установлено в true。

Язык кода:javascript
копировать
appendonly yes
aof-use-rdb-preamble yes

Соответствующий метод сохранения

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

  • данные в режиме реального времени и согласованность:есливерноданные в режиме реального времени и согласованность Есть очень высокиеиз Требовать,Тогда AOF может быть лучшим выбором. Если требования к реальному времени и согласованности не слишком высоки,И хотите быстро загрузить данные и сократить использование дискового пространства.,Что RDB может больше подойти для вашего приложения. Поскольку файл RDB имеет двоичный формат.,Очень компактная структура,Таким образом, существующие Redis могут быстро загружать данные при перезапуске.
  • Редис Требования к производительности:есливерно Редис性能Есть очень высокиеиз Требовать,Также можно отключить функцию сохранения. Поскольку функция персистентности может повлиять на производительность Редиса.,Дав целом Нетпредположениеэтот Что?做。

Подвести итог

На этом статья заканчивается. Наконец, давайте сделаем небольшой вывод.

нам нужно осознать Редис Механизм персистентности играет решающую рольиз Роль。Каждый из двух основных методов сохранения данных (RDB и AOF) имеет свои преимущества и сценарии использования.

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

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

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

boy illustration
Неразрушающее увеличение изображений одним щелчком мыши, чтобы сделать их более четкими артефактами искусственного интеллекта, включая руководства по установке и использованию.
boy illustration
Копикодер: этот инструмент отлично работает с Cursor, Bolt и V0! Предоставьте более качественные подсказки для разработки интерфейса (создание навигационного веб-сайта с использованием искусственного интеллекта).
boy illustration
Новый бесплатный RooCline превосходит Cline v3.1? ! Быстрее, умнее и лучше вилка Cline! (Независимое программирование AI, порог 0)
boy illustration
Разработав более 10 проектов с помощью Cursor, я собрал 10 примеров и 60 подсказок.
boy illustration
Я потратил 72 часа на изучение курсорных агентов, и вот неоспоримые факты, которыми я должен поделиться!
boy illustration
Идеальная интеграция Cursor и DeepSeek API
boy illustration
DeepSeek V3 снижает затраты на обучение больших моделей
boy illustration
Артефакт, увеличивающий количество очков: на основе улучшения характеристик препятствия малым целям Yolov8 (SEAM, MultiSEAM).
boy illustration
DeepSeek V3 раскручивался уже три дня. Сегодня я попробовал самопровозглашенную модель «ChatGPT».
boy illustration
Open Devin — инженер-программист искусственного интеллекта с открытым исходным кодом, который меньше программирует и больше создает.
boy illustration
Эксклюзивное оригинальное улучшение YOLOv8: собственная разработка SPPF | SPPF сочетается с воспринимаемой большой сверткой ядра UniRepLK, а свертка с большим ядром + без расширения улучшает восприимчивое поле
boy illustration
Популярное и подробное объяснение DeepSeek-V3: от его появления до преимуществ и сравнения с GPT-4o.
boy illustration
9 основных словесных инструкций по доработке академических работ с помощью ChatGPT, эффективных и практичных, которые стоит собрать
boy illustration
Вызовите deepseek в vscode для реализации программирования с помощью искусственного интеллекта.
boy illustration
Познакомьтесь с принципами сверточных нейронных сетей (CNN) в одной статье (суперподробно)
boy illustration
50,3 тыс. звезд! Immich: автономное решение для резервного копирования фотографий и видео, которое экономит деньги и избавляет от беспокойства.
boy illustration
Cloud Native|Практика: установка Dashbaord для K8s, графика неплохая
boy illustration
Краткий обзор статьи — использование синтетических данных при обучении больших моделей и оптимизации производительности
boy illustration
MiniPerplx: новая поисковая система искусственного интеллекта с открытым исходным кодом, спонсируемая xAI и Vercel.
boy illustration
Конструкция сервиса Synology Drive сочетает проникновение в интрасеть и синхронизацию папок заметок Obsidian в облаке.
boy illustration
Центр конфигурации————Накос
boy illustration
Начинаем с нуля при разработке в облаке Copilot: начать разработку с минимальным использованием кода стало проще
boy illustration
[Серия Docker] Docker создает мультиплатформенные образы: практика архитектуры Arm64
boy illustration
Обновление новых возможностей coze | Я использовал coze для создания апплета помощника по исправлению домашних заданий по математике
boy illustration
Советы по развертыванию Nginx: практическое создание статических веб-сайтов на облачных серверах
boy illustration
Feiniu fnos использует Docker для развертывания личного блокнота Notepad
boy illustration
Сверточная нейронная сеть VGG реализует классификацию изображений Cifar10 — практический опыт Pytorch
boy illustration
Начало работы с EdgeonePages — новым недорогим решением для хостинга веб-сайтов
boy illustration
[Зона легкого облачного игрового сервера] Управление игровыми архивами
boy illustration
Развертывание SpringCloud-проекта на базе Docker и Docker-Compose