10 минут, чтобы полностью понять механизм сохранения Redis: RDB и AOF.

Redis задняя часть

Оригинальный автор, публичный аккаунт [программист чтение], прошу обратить внимание на паблик аккаунт, просьба указывать источник перепечатываемой статьи.

В этой статье мы продолжим оRedisДавайте узнаем об одной из самых важных вещей:Redisмеханизм постоянства.

Что такое постоянство Redis?

Redisв виде пары ключ-значение в памяти базы данных (NoSQL), данные хранятся в памяти, и при обработке клиентских запросов все операции выполняются в памяти следующим образом:

Что плохого в этом?

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

только дляRedisКогда кеш используется для проекта, исчезновение данных может не быть проблемой, и данные могут быть загружены из источника данных снова, но если бизнес-данные, отправленные пользователем, хранятся непосредственно вRedisСреди них поставитьRedisИспользуется в качестве базы данных для хранения важных бизнес-данных, а затемRedisПоследствия потери данных памяти могут быть разрушительными.

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

Redisпри условииRDBиAOFДва разных метода сохранения данных, давайте подробно представим эти разные методы сохранения.

RDB

RDBЭто метод сохраняемости моментальных снимков, который заключается в храненииRedisДанные памяти в определенное время сохраняются в файл на жестком диске, а имя файла, сохраненное по умолчанию, называетсяdump.rdb, пока вRedisКогда сервер запустится, он будет перезагруженdump.rdbДанные файла восстанавливаются в памяти.

Включить сохраняемость RDB

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

1. сохранить команду

saveКоманда является синхронной операцией.

# 同步数据到磁盘上
> save

Когда клиент отправляет на серверsaveСервер блокируется, когда запрос команды сохраняетсяsaveЗапросы от других клиентов после команды до завершения синхронизации данных.

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

2. bgsave

иsaveразличные команды,bgsaveКоманда является асинхронной операцией.

# 异步保存数据集到磁盘上
> bgsave

Когда клиент отправляет услугуbgsaveКогда приказали,RedisОсновной серверный процесс будетforksДочерний процесс для проблемы синхронизации данных, после сохранения данных в файл rdb дочерний процесс завершится.

Итак, сsaveпо сравнению с командойRedisсервер обрабатываетbgsaveИспользуйте дочерние потоки для записи ввода-вывода, в то время как основной процесс все еще может получать другие запросы, ноforksДочерний процесс является синхронным, поэтомуforksКогда это дочерний процесс, он не может получать другие запросы, а это означает, что если разветвление дочернего процесса занимает слишком много времени (обычно очень быстро), команда bgsave по-прежнему блокирует запросы других клиентов.

3. Конфигурация сервера запускается автоматически

Помимо отправки команд через клиент, есть еще один способ, то есть вRedisв файле конфигурацииsaveУкажите условие, которое запускает сохраняемость RDB, например [сколько операций записи выполняется как минимум за сколько секунд], чтобы открытьRDBсинхронизация данных.

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

# 900s内至少达到一条写命令
save 900 1
# 300s内至少达至10条写命令
save 300 10
# 60s内至少达到10000条写命令
save 60 10000

Затем файл конфигурации загружается при запуске сервера.

# 启动服务器加载配置文件
redis-server redis.conf

Этот метод запуска RDB через файл конфигурации сервера аналогичен команде bgsave.При достижении условия запуска он разветвляет дочерний процесс для синхронизации данных, но лучше не запускать сохранение RDB таким образом, потому что параметр слишком короткое время запуска, легко часто записывать в файл rdb, что влияет на производительность сервера.Если установка времени слишком длинная, это приведет к потере данных.

RDB-файл

Выше описаны три способа позволить серверу генерировать RDB-файлы, независимо от того, генерируется ли он основным процессом или подпроцессом.

  1. Создайте временный файл rdb и запишите данные.
  2. Завершите запись данных и замените официальный файл rdb временным текстом.
  3. Удалите исходный файл БД.

Имя файла, сгенерированное RDB по умолчанию, — dump.rdb.Конечно, я могу настроить его более подробно через файл конфигурации.Например, когда несколько процессов сервера redis запускаются под одной машиной, разные имена rdb можно настроить через номер порта, как показано ниже:

# 是否压缩rdb文件
rdbcompression yes

# rdb文件的名称
dbfilename redis-6379.rdb

# rdb文件保存目录
dir ~/redis/

Несколько преимуществ RDB

  1. По сравнению с методом AOF восстановление данных через файлы rdb происходит быстрее.
  2. rdb очень компактны и подходят для резервного копирования данных.
  3. Резервное копирование данных через RDB мало влияет на производительность сервера Redis из-за использования генерации подпроцессов.

Несколько недостатков RDB

  1. Если сервер не работает, используйтеRDBЭтот метод приведет к потере данных через определенный период времени, например, если мы установим синхронизацию один раз в 10 минут или один раз в 5 минут при достижении 1000 записей, то, если сервер выйдет из строя до достижения условия триггера, данные в этот период будет потерян.
  2. Использование команды сохранения приведет к блокировке сервера, и последующие запросы могут быть получены только после завершения синхронизации данных.
  3. Когда команда bgsave используется для разветвления дочернего процесса, если объем данных слишком велик, процесс разветвления также будет заблокирован.Кроме того, дочерний процесс разветвления будет потреблять память.

AOF

закончил говоритьRDB, давай поболтаемRedisДругой метод сохранения:AOF(Append-only file).

иRDBХранение снимка в определенный момент отличается,AOFPersistence будет записывать каждую команду операции записи от клиента к серверу и сохранять эти операции записи в видеRedisДобавление протокола сохраняется в суффиксе какaofВ конце файла при перезагрузке сервера Redis он будет загружен и запущенaofфайловые команды с целью восстановления данных.

Включить сохранение AOF

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

# 开启aof机制
appendonly yes

# aof文件名
appendfilename "appendonly.aof"

# 写入策略,always表示每个写操作都保存到aof文件中,也可以是everysec或no
appendfsync always

# 默认不重写aof文件
no-appendfsync-on-rewrite no

# 保存目录
dir ~/redis/

Три стратегии записи

В приведенном выше файле конфигурации мы можем передатьappendfsyncoption указывает стратегию записи, есть три варианта

appendfsync always
# appendfsync everysec
# appendfsync no
1. always

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

2. everysec

appendfsyncПолитика записи по умолчанию, запись один раз в секунду.aofфайла, поэтому может быть потеряно до 1 с данных.

3. no

RedisСервер не несет ответственности за написаниеaof, но оставьте на усмотрение операционной системы, когда писатьaofдокумент. Более быстрый, но наименее безопасный вариант и не рекомендуется.

Перезапись файла AOF

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

incr num 1
incr num 2
incr num 3
incr num 4
incr num 5
incr num 6
...
incr num 100000

Файл aof слишком велик. При загрузке файла aof для восстановления данных он будет очень медленным. Чтобы решить эту проблему, Redis поддерживает перезапись файла aof. При перезаписи файла aof требуется минимальный набор команд для восстановление текущих данных может быть сгенерировано, например, как в приведенном выше примере.Так много команд можно переписать как:

set num 100000

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

Два способа переписать

Через параметр no-appendfsync-on-rewrite в конфигурационном файле redis.conf можно указать, включать ли перезапись.Этот метод будет перезаписываться каждый раз при fsync, что будет влиять на производительность сервера.Поэтому значение по умолчанию - нет, что не рекомендуется использовать.

# 默认不重写aof文件
no-appendfsync-on-rewrite no

Клиент отправляет серверу команду bgrewriteaof, и сервер также может выполнять перезапись AOF.

# 让服务器异步重写追加aof文件命令
> bgrewriteaof

Метод перезаписи AOF также является асинхронной операцией, то есть, если файл aof должен быть записан, основной процесс Redis разветвит дочерний процесс для его обработки, как показано ниже:

Преимущества перезаписи файлов aof

  1. Сжимайте файлы, чтобы уменьшить использование диска.

  2. Команда aof сжата в минимальный набор команд, что увеличивает скорость восстановления данных.

Повреждение файла AOF

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

  1. Сделайте резервную копию файла now aof на всякий случай.

  2. Используйте команду redis-check-aof для восстановления файла aof Формат команды следующий:

# 修复aof日志文件
$ redis-check-aof -fix file.aof
  1. Перезапустите сервер Redis, загрузите восстановленный файл aof и восстановите данные.

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

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

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

  1. Файл журнала, сгенерированный методом AOF, слишком велик.Даже если он перезаписывается с помощью AFO, размер файла все равно велик.

  2. Восстановление данных происходит медленнее, чем RDB.

Должен ли я выбрать RDB или AOF?

Благодаря приведенному выше введению мы понимаем преимущества и недостатки RDB и AOF Как выбрать?

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

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

резюме

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

Ваше внимание — самое большое поощрение на моем писательском пути!

Категории