Количество слов: 8059 слов. Чтение занимает около 25 минут.
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 — это метод сохранения данных Redis по умолчанию (AOF по умолчанию отключен). Он записывает данные Redis в память на жесткий диск и создает файл моментального снимка.
Файл моментального снимка — это двоичный файл, содержащий все данные Redis на определенный момент времени.
Преимущество RDB в том, что он быстрый, простой и подходит для резервного копирования и восстановления крупномасштабных данных.
Однако у RDB есть и недостатки, например, данные могут быть потеряны, поскольку Redis создает файлы моментальных снимков только в определенный момент времени. Если сервер выйдет из строя после создания файла моментального снимка, но до того, как будет создан следующий файл моментального снимка, данные за этот период будут потеряны.
Как показано на рисунке ниже, если сервер выйдет из строя в момент T2, данные на ключах k3 и k4 могут быть потеряны.
Поскольку файл RDB сохраняется в двоичном формате, он очень компактен и быстро загружает данные при перезапуске Redis. По сравнению с AOF файлы RDB обычно меньше.
Существует два способа активировать сохранение RDB: автоматический и ручной.
Руководство: пройти вручную save
команда или bgsave
Заказ продолжается.
Автоматический: автоматический режим задается в файле конфигурации и автоматически запускается при выполнении условий.
Ручной режим
Во время выполнения команды bgsave команды save и bgsave, отправленные клиентом, будут отклонены. Это необходимо для предотвращения конкуренции между родительским и дочерним процессами.
автоматический режим
автоматический режимдаотносится к прохождениюсерверфайл конфигурации save вариант, давай Redis Автоматически выполнять время от времени bgsave , по существу через bgsave команду для реализации.
Опция сохранения файла конфигурации позволяет настроить несколько условий. При выполнении любого из условий будет срабатывать bgsave.
То есть: когда выполняется условие «набор данных имеет не менее M изменений в течение N секунд».
Например, если мы предоставим серверу следующую конфигурацию:
save 900 1
save 300 10
save 60 10000
Затем, если выполнено любое из следующих трех условий, команда bgsave будет выполнена:
Если пользователь не устанавливает параметр сохранения активно, сервер установит для параметра сохранения условия по умолчанию:
save 900 1
save 300 10
save 60 0000
Зная вышесказанное, нам еще нужно решить две задачи:
Вопрос 1. Как Redis определяет конфигурацию параметров сохранения?
Сервер Redis внутренне поддерживает счетчик:грязный и метку времени:lastsave.
Например, в определенный момент значения счетчика загрязнений и метки времени последнего сохранения следующие:
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 следует отметить два момента:
Ниже приведены некоторые конфигурации параметров, связанные с RDB:
Постоянство AOF добавляет команды записи в конец дискового файла в порядке команд записи Redis. Это метод сохранения на основе журнала, который сохраняет записи журнала всех операций записи на сервере Redis.
Основная идея AOF — добавлять в файл все команды записи, выполняемые сервером Redis. При перезапуске сервера Redis его состояние можно восстановить, повторно выполнив команды в AOF.
Простой пример файла AOF выглядит следующим образом:
В этом файле показаны две команды:
select 0
set k1 hello
в:
Все команды, сохраненные в файле AOF, имеют один и тот же формат, то есть, начиная с *, указывается количество параметров, начиная с $, указывается длина параметра, за которым следует значение параметра.
У AOF есть лучшее преимущество: он может восстанавливать ошибки в работе.
Например, если вы случайно выполните FLUSHALL
команда, что приводит к случайному удалению данных. , но пока AOF Файл не был перезаписан, тогда просто остановите сервер и удалите AOF в конце файла FLUSHALL
команду и перезапуск Redis , вы можете восстановить набор данных в FLUSHALL
Состояние перед казнью.
Когда AOF включен, когда Redis записывает команду, он фактически не записывает ее непосредственно в файл AOF. Вместо этого он добавляет команду записи в конец буфера AOF, а затем буфер AOF синхронизируется с файлом AOF.
Такое поведение на самом деле нетрудно понять. Redis очень часто записывает команды, а файл AOF находится на диске. Если с диском нужно работать каждый раз, когда возникает команда записи, производительность будет значительно снижена.
и AOF Кэш синхронизируется с AOF файл, процесс, называемый flushAppendonlyFile
функция завершена.
и flushAppendOnlyFile
Поведение функции определяется файлом конфигурации сервера. appendfsync
Этот параметр имеет следующие три параметра:
По умолчанию Редис 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 реализуется путем чтения текущего состояния базы данных сервера.
Позвольте мне привести пример, чтобы каждый мог понять. Предположим, я выполняю в Redis следующие шесть команд:
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 можно разделить на следующие этапы:
Redis предоставляет команды для ручного запуска перезаписи AOF. BGREWRITEAOF
, процесс перезаписи выполняется родительским процессом fork Его завершает выходящий дочерний процесс, во время которого родительский процесс может продолжать обработку запроса.
Вы можете выполнить эту команду в клиенте Существующий Редис, чтобы запустить процесс перезаписи AOF. Редис 2.2 Необходимо выполнить вручную BGREWRITEAOF
Заказал, прибыл Redis 2.4 может запускаться автоматически Переписать АОФ。
Конкретные шаги заключаются в следующем:
Откройте инструмент командной строки redis-cli и подключитесь к службе Redis.
осуществлятьBGREWRITEAOF
Заказ,Запустите процесс перезаписи AOF.
$ redis-cli
127.0.0.1:6379> BGREWRITEAOF
Redis вернет идентификатор фоновой задачи, указывая, что задача перезаписи AOF запущена.
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started by pid 1234
Можно использовать INFO PERSISTENCE
Используйте команду, чтобы проверить размер текущего файла AOF и состояние процесса, и дождитесь завершения процесса.
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 Четыре ключа.
Чтобы решить эту проблему несогласованности данных, сервер 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 станут недействительными и потеряются, поэтому будет сохранена только часть Заказа),и Область кэша перезаписи АОФ нет).
В файле конфигурации Redis redis.conf вы можете установить параметры, связанные с 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, что приведет к повреждению файла AOF.
происходитьэтотситуациячас,Можно использовать Redis Входит в комплект redis-check-aof программа, да AOF Чтобы восстановить файл, команда выглядит следующим образом:
$ redis-check-aof –fix
Что нам более знакомо, так это журнал упреждающей записи (WAL) базы данных. Это означает, что перед фактической записью данных измененные данные записываются в файл журнала, чтобы облегчить восстановление в случае сбоя.
Например, журнал повторов в механизме хранения MySQL Innodb использует журналирование с упреждающей записью.
Однако АОФ В журнале всё наоборот, это да Журнал после записи,«После записи» означает, что Redis сначала выполняет Заказ и записывает данные в память.,Затем запишите журнал。
Думая: почему это сделано именно так?
Фактически, чтобы избежать дополнительных затрат на проверку, Redis не выполняет сначала проверку синтаксиса этих команд при записи журналов в AOF. Поэтому, если сначала записать журнал, а затем выполнить команду, в журнал может быть записана неверная команда, и Redis может допустить ошибку при использовании журнала для восстановления данных.
и Журнал после Таким образом, пусть система сначала выполнит заказ. Только если команда может быть выполнена успешно, она будет записана в журнал. В противном случае система напрямую сообщит клиенту об ошибке. Итак, Редис Одним из больших преимуществ использования ведения журнала после записи является то, что оно позволяет избежать записи неверных команд и снизить затраты на проверку синтаксиса.
Кроме того, Журнал пост-записи AOF имеет еще одно преимущество: он записывает журнал только после выполнения команды дасуществовать.,Таким образом, он не будет блокировать текущий процесс записи.
Однако ведение журнала после записи также несет в себе два потенциальных риска:
в прошлом, Redis Пользователи обычно 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。
appendonly yes
aof-use-rdb-preamble yes
Если вы хотите выбрать правильный метод сохранения для вашего приложения, вам необходимо учитывать следующие два фактора:
На этом статья заканчивается. Наконец, давайте сделаем небольшой вывод.
нам нужно осознать Редис Механизм персистентности играет решающую рольиз Роль。Каждый из двух основных методов сохранения данных (RDB и AOF) имеет свои преимущества и сценарии использования.。
RDB предоставляет снимок определенного момента времени с помощью,Очень эффективен для аварийного восстановления и AOF благодаря протоколированию каждой операции записи;,Лучшая гарантия долговечности данных. Однако,У них также есть свои ограничения,Для этого необходимо взвесить, какой метод сохранения выбрать в зависимости от реальных потребностей.
Наконец, нельзя игнорировать тот факт, что при выборе подходящей стратегии персистентности мы также должны учитывать, как сбалансировать множество факторов, таких как использование памяти, использование диска, производительность и долговечность. Только при глубоком понимании персистентности Redis мы сможем в полной мере использовать его мощные функции для удовлетворения различных потребностей бизнеса.
Я надеюсь, что эта статья поможет вам узнать и о чем подумать.,Если у вас также есть опыт, из которого вы можете извлечь уроки и глубоко задуматься,Добро пожаловать, чтобы оставить сообщение в области комментариев для обсуждения.