Следуйте за мной, чтобы получать последние знания, классические вопросы для интервью и делиться технологиями микросервисов.
1. Настойчивость
1.1 Введение в постоянство
Постоянство: Постоянство — это механизм преобразования данных программы между постоянным состоянием и переходным состоянием, то есть сохранение данных (например, объектов в памяти) на запоминающем устройстве (например, на диске), которое можно сохранить навсегда.
1.2 повторное сохранение
Redis — это база данных в памяти.Чтобы предотвратить потерю данных сервера после простоя сервера и выхода из серверного процесса, Redis предоставляет функцию сохранения, то есть сохраняет данные в памяти в Redis на диск. Redis обеспечивает различные уровни постоянства:
- Режим сохраняемости RDB: хранение моментальных снимков данных может выполняться через определенные промежутки времени.
- Метод сохраняемости AOF: записывайте каждую операцию записи на сервер. При перезапуске сервера эти команды будут выполняться повторно для восстановления исходных данных. Команда AOF добавляет протокол redis для сохранения каждой операции записи в конец файла. Redis может также Файл AOF перезаписывается в фоновом режиме, так что размер файла AOF не будет слишком большим.
Если на сервере включено сохранение AOF. Сервер будет предпочтительно использовать файлы AOF для восстановления данных. Только когда функция сохранения AOF отключена, сервер будет использовать файл RDB для восстановления данных.
2. Постоянство RDB
2.1 Формат файла RDB
Файл RDB представляет собой сжатый двоичный файл (имя файла по умолчанию: dump.rdb), состоящий из нескольких частей, в формате RDB:
2.2 Постоянное создание и загрузка файла RDB
Когда Redis сохраняется, программа RDB сохраняет текущее состояние базы данных в памяти в файл на диске.При перезапуске Redis программа RDB может восстановить состояние базы данных, загрузив файл RDB.
2.3 Как это работает
Когда Redis необходимо сохранить файл dump.rdb, сервер делает следующее:
- Вилки вызовов Redis. Иметь как родительские, так и дочерние процессы.
- Подпроцесс записывает набор данных во временный файл RDB.
- Когда дочерний процесс завершает запись в новый файл RDB, Redis заменяет старый файл RDB новым файлом RDB и удаляет старый файл RDB.
Такой способ работы позволяет Redis использовать механизм копирования при записи.
2.4 Как создать
SAVE
Синхронная работа, при выполнении команды сервер будет заблокирован, а командный запрос, отправленный клиентом, будет отклонен
redis> save
Асинхронная операция, когда команда выполняется, дочерний процесс выполняет работу по сохранению, а сервер может продолжать позволять основному потоку обрабатывать командный запрос, отправленный клиентом.
redis>bgsave
Поскольку команду BGSAVE можно выполнять, не блокируя серверный процесс, пользователь может настроить атрибут сохранения и позволить серверу автоматически выполнять команду BGSAVE один раз в каждый период времени (то есть настроить Redis через файл конфигурации, чтобы набор данных имеет не менее "N секунд". Когда выполняется условие "M изменений", автоматически выполняется операция сохранения набора данных).
比如：
/*服务器在900秒之内，对数据库进行了至少1次修改*/
Save 900 1
/*服务器在300秒之内，对数据库进行了至少10次修改*/
Save 300 10
/*服务器在60秒之内，对数据库进行了至少10000次修改*/
Save 60 10000
Команда BGSAVE будет выполняться до тех пор, пока выполняется одно из условий.
2.5 Конфигурация RDB по умолчанию
################################ SNAPSHOTTING ################################
#
# Save the DB on disk:
#在给定的秒数和给定的对数据库的写操作数下，自动持久化操作。
# save <seconds> <changes>
#
save 900 1
save 300 10
save 60 10000
#bgsave发生错误时是否停止写入，一般为yes
stop-writes-on-bgsave-error yes
#持久化时是否使用LZF压缩字符串对象?
rdbcompression yes
#是否对rdb文件进行校验和检验，通常为yes
rdbchecksum yes
# RDB持久化文件名
dbfilename dump.rdb
#持久化文件存储目录
dir ./
3. Стойкость АОФ
3.1 Введение в сохраняемость AOF
Постоянство AOF записывает состояние базы данных, сохраняя команды записи, выполняемые сервером Redis.
Реализация функции сохранения AOF:
-
Append command append: Когда функция сохраняемости AOF включена, сервер выполняет команду записи и добавляет команду, выполненную в формате протокола, в конец буфера aof_buf состояния сервера.
reids>SET KET VAULE //协议格式 \r\n$3\r\nSET\r\n$3\r\nKEY\r\n$5\r\nVAULE\r\n -
Синхронизация записи и синхронизации файлов. Процесс сервера Redis представляет собой цикл событий, и это событие файла отвечает за получение запросов команд от клиентов и отправку ответов на команды клиентам. При выполнении команды append сервер вызовет функцию flushAppendOnlyFile, необходимо ли записать и сохранить содержимое буфера AOF в файл AOF.
redis> SET msg "Ccww" redis> SADD persistence "rdb" "aof" redis> RPUSH size 128 256 512
3.2 Стратегия сохранения AOF
Стратегия сохранения AOF (т. е. запись содержимого буфера и синхронизация синхронизации с AOF), вы можете выбрать стратегию сохранения AOF, настроив атрибут appendfsync:
- всегда: записывайте и синхронизируйте все содержимое буфера aof_buf с файлом AOF и выполняйте fsync каждый раз, когда к файлу AOF добавляется новая команда.
- каждую секунду (по умолчанию): если время последней синхронизации AOF превышает одну секунду, сначала запишите все содержимое буфера aof_buf в файл AOF, затем снова синхронизируйте файл AOF, и операция синхронизации будет выполнена выделенная ветка.
- Нет: записывает все содержимое в буфере AOF_BUF в файл AOF, но не синхронизирует файл AOF. Когда синхронизировать определяется операционной системой (ОС).
Эффективность и безопасность стратегии сохраняемости AOF:
- Всегда: самый медленный по эффективности, но самый безопасный с точки зрения безопасности, даже в случае сбоя и простоя постоянство потеряет только данные команды одного цикла событий.
- Everysec: Принимая во внимание как скорость, так и безопасность, при простое теряется только одна секунда командных данных.
- Нет: Запись выполняется быстрее всего, но, как правило, одна синхронизация занимает больше всего времени, и все данные команды после загрузки и синхронизации файла AOF будут потеряны в случае простоя.
3.3 Переписать AOF
Поскольку постоянство AOF добавит выполненные команды записи в файл AOF, количество команд записи со временем будет увеличиваться, а размер файла AOF также будет становиться все больше и больше. Большой размер файла AOF влияет на сервер Reids и даже на хост-сервер.
Чтобы решить проблему расширения объема файла AOF, Redis предоставляет функцию перезаписи файла AOF:
- Создайте новый файл AOF, который не сохраняет избыточные команды, занимающие место впустую, а новый и старый файлы AOF сохраняют одно и то же состояние базы данных.
- Новый файл AOF реализуется путем чтения пар ключ-значение в базе данных, и программе не нужно читать, анализировать или записывать существующий файл AOF.
- Во избежание переполнения буфера, при перезаписи list, hash, set и Zset, при превышении установленного постоянного номера, в наборе будет записано несколько одинаковых команд.
- Redis 2.4 может автоматически запускать перезапись AOF через конфигурацию, запуская параметры
auto-aof-rewrite-percentage(скорость роста, которая запускает перезапись файла AOF)а такжеauto-aof-rewrite-min-size(Минимальный размер для запуска файла AOF для выполнения перезаписи)
Роль AOF переписать:
- Уменьшить использование диска
- Ускорьте восстановление данных
Сервер Redis использует один поток для обработки командных запросов.Сервер вызывает функцию aof_rewrite в больших количествах.В течение периода перезаписи AOF командный запрос, отправленный клиентом, не может быть обработан.Поэтому программа перезаписи AOF выполняется в дочернем Преимущества:
- Во время перезаписи AOF дочернего процесса серверный процесс может продолжать обрабатывать запросы команд.
- Дочерний процесс имеет копию данных серверного процесса, что обеспечивает безопасность данных.
Перезапись AOF с использованием подпроцессов приведет к несогласованности базы данных с данными, сохраненными перезаписанным AOF.Чтобы решить эту несогласованность данных, Redis использует AOF для перезаписи буфера. выполнить:
- Выполнение команды при добавлении команды к буферу AOF и буферу перезаписи AOF
- Когда дочерний процесс AOF перезаписывается, он отправляет сигнал родительскому процессу, и родительский процесс записывает все содержимое буфера перезаписи AOF в новый файл AOF.Состояние базы данных, сохраненное в новом файле AOF, будет таким же, как текущая база данных сервера.Статус тот же.
- Переименуйте новый файл AOF, атомарно перезапишите существующий файл AOF и завершите процесс замены старого и нового файлов AOF.
3.4 Параметры сохраняемости AOF по умолчанию
############################## APPEND ONLY MODE ###############################
#开启AOF持久化方式
appendonly no
#AOF持久化文件名
appendfilename "appendonly.aof"
#每秒把缓冲区的数据fsync到磁盘
appendfsync everysec
# appendfsync no
#是否在执行重写时不同步数据到AOF文件
no-appendfsync-on-rewrite no
# 触发AOF文件执行重写的增长率
auto-aof-rewrite-percentage 100
#触发AOF文件执行重写的最小size
auto-aof-rewrite-min-size 64mb
#redis在恢复时，会忽略最后一条可能存在问题的指令
aof-load-truncated yes
#是否打开混合开关
aof-use-rdb-preamble yes
4 Резюме и выбор метода персистентности
4.1 Преимущества и недостатки RDB
Преимущества RDB
- RDB - очень компактный файл. Он сохраняет набор данных в определенный момент времени. Он очень подходит для резервного копирования набора данных. Например, вы можете сохранить данные за последние 24 часа в каждом почасовом отчете и сохранить прошлые 30 дней каждый день данные, так что даже если что-то пойдет не так, вы сможете восстановить другую версию набора данных в соответствии с вашими потребностями.
- Благодаря компактности файлов RDB легко реплицировать данные в удаленный центр обработки данных, что очень удобно для аварийного восстановления.
- Когда RDB сохраняет файл RDB, единственное, что нужно сделать родительскому процессу, — это разветвить дочерний процесс, а следующая работа выполняется дочерним процессом Родительскому процессу не нужно выполнять другие операции ввода-вывода, поэтому сохраняемость RDB метод может максимизировать производительность Redis.
- По сравнению с AOF метод RDB будет быстрее при восстановлении больших наборов данных.
Недостатки РБД
- Если вы хотите, чтобы наименьшее количество данных было потеряно в случае, если Redis неожиданно перестанет работать (например, отключение питания), тогда RDB не для вас, хотя вы можете настроить разные точки времени сохранения (например, каждые 5 минут и иметь 100 сохранений для операции записи набора данных). ), для Redis относительно тяжелая работа по полному сохранению всего набора данных. Обычно полное сохранение выполняется каждые 5 минут или чаще. В случае непредвиденного простоя в Redis вы можете потерять данные в минутах данных.
- RDB необходимо часто разветвлять подпроцессы, чтобы сохранить набор данных на жесткий диск.Когда набор данных относительно велик, процесс разветвления занимает очень много времени, что может привести к тому, что Redis не сможет отвечать на запросы клиентов в течение нескольких миллисекунд. набор данных огромен. И если производительность процессора не очень хорошая, эта ситуация будет длиться 1 секунду, AOF также нуждается в форке, но вы можете настроить частоту перезаписи файла журнала, чтобы улучшить долговечность набора данных.
4.2 Преимущества и недостатки АОФ
Преимущества АОФ:
- Использование AOF сделает ваш Redis более надежным: используйте разные стратегии fsync: без fsync, fsync в секунду, fsync при каждой записи.Со стратегией fsync по умолчанию по умолчанию Redis по-прежнему работает хорошо (fsync выполняется фоновым потоком). основной поток будет стараться изо всех сил обрабатывать запросы клиентов), в случае сбоя вы потеряете до 1 секунды данных.
- Файл AOF является файлом журнала только для добавления, поэтому поиск записи не требуется.Даже если полная команда записи не выполняется по каким-либо причинам (дисковое пространство заполнено, сбой во время записи и т. д.), вы можете использовать Инструмент redis-check-aof устраняет проблемы.
- Redis может автоматически перезаписывать AOF, когда размер файла AOF становится слишком большим: новый файл AOF после перезаписи содержит минимальный набор команд, необходимых для восстановления текущего набора данных. Вся операция перезаписи абсолютно безопасна, поскольку Redis продолжит добавлять команды к существующему файлу AOF в процессе создания нового файла AOF.Даже если во время процесса перезаписи произойдет отключение, существующий файл AOF не будет потерян. . После создания нового файла AOF Redis переключится со старого файла AOF на новый файл AOF и начнет добавление к новому файлу AOF.
- Файл AOF сохраняет все операции записи, выполняемые в базу данных, в упорядоченном порядке, и эти операции записи сохраняются в формате протокола Redis, поэтому содержимое файла AOF очень легко читается людьми, и это также очень легко разобрать файл. Экспорт файлов AOF также очень прост (например, если вы случайно выполнили команду FLUSHALL, но пока файл AOF не перезаписан, просто остановите сервер, удалите команду FLUSHALL в конце файла AOF и перезапустите Redis). . восстановить набор данных в состояние, в котором он был до выполнения FLUSHALL).
Недостатки АОФ:
- Для одного и того же набора данных размер файлов AOF обычно больше, чем размер файлов RDB.
- В зависимости от используемой стратегии fsync AOF может работать медленнее, чем RDB. В целом производительность fsync в секунду по-прежнему очень высока, и отключение fsync может сделать AOF таким же быстрым, как RDB, даже при большой нагрузке. Однако при работе с огромными нагрузками записи RDB может обеспечить более гарантированную максимальную задержку (латентность).
4.3 Как выбрать, какой метод персистентности использовать?
В общем, если вы хотите добиться безопасности данных, сравнимой с PostgreSQL, вам следует использовать обе функции сохранения.
Если вы очень заботитесь о своих данных, но можете допустить потерю данных в течение нескольких минут, вы можете просто использовать постоянство RDB.
Есть много пользователей, которые используют только настойчивость AOF, но мы не рекомендуем этот метод: поскольку очень удобно регулярно генерировать снимки RDB для резервного копирования базы данных, а скорость восстановления данных RDB - это быстрее, чем у af Recovery наборов данных. Добавление, использование RDB может избежать ошибки программы AOF, упомянутой ранее.
Вы в порядке, офицеры? Если вам это нравится, проведите пальцем, чтобы нажать 💗, нажмите, чтобы подписаться! ! Спасибо за Вашу поддержку!
Добро пожаловать в публичный аккаунт【Технический блог Ccww], впервые была запущена оригинальная техническая статья