предисловие
Как мы все знаем, Redis — это in-memory БД, так как данные хранятся в памяти, то данные, естественно, будут потеряны после выхода в офлайн, в нашем бизнесе такая ситуация, конечно, недопустима, поэтому нам нужно задействовать Redis на данный момент. , механизм сохранения
Redis может вручную включить постоянство для сохранения данных в памяти на диск.Redis предоставляет следующие две схемы сохранения:
- Моментальный снимок RDB
- Журнал АОФ
Далее мы объясним эти два метода
Моментальный снимок RDB
Принцип моментального снимка rdb заключается в периодическом сохранении данных в Redis.Также можно понять, что Redis время от времени сохраняет состояние текущих данных памяти на диск.
Эта конкретная операция не завершается рабочим процессом. Redis вызовет функцию fork для создания дочернего процесса. Родительский процесс обычно выполняет операцию запроса, отправленную клиентом, а дочерний процесс записывает текущий моментальный снимок базы данных во временную память. файл и, наконец, замените исходный файл (по умолчанию dump.rdb)
Благодаря механизму копирования при записи в операционной системе родительский и дочерний процессы совместно используют физические страницы.Когда родительский процесс обрабатывает запрос на запись, операционная система создает копию страницы, которая будет изменена родительским процессом, поэтому данные в адресном пространстве дочернего процесса это только текущий момент.Снапшот всей БД,поэтому этот метод и называетсяснимок RDBпричина
Преимущества такого подхода очевидны:
- В режиме RDB непрерывно генерируются файлы моментальных снимков, которые представляют данные в Redis в определенное время и могут использоваться в качестве холодного резервного копирования.
- Используя подпроцессы для выполнения дискового ввода-вывода, влияние на Redis при записи моментальных снимков очень мало, и можно поддерживать высокую производительность Redis.
- Скорость перезапуска и восстановления данных Redis высокая.
Но есть у него и недостатки:
- Если между моментальными снимками произойдет сбой, данные, записанные между ними, будут потеряны.
- При каждом форке, если данных очень много, сервис будет приостановлен на определенный период времени.
Redis включает этот метод сохранения по умолчанию. Вы можете открыть файл redis.conf. Если это оконная система, откройте redis.window.conf (файл redis.windows-service.conf — это файл конфигурации, загружаемый, когда системная служба Если вы установите Redis в качестве системной службы, просто откройте ее), вы найдете следующие конфигурации:
save 900 1
save 300 10
save 60 10000
Мы принимаемsave 900 1Возьмите эту конфигурацию в качестве примера, ее значение在900秒内，如果至少有1个key值发生了变化，就进行内存快照, мы также можем обнаружить, что эти операторы сохранения могут появляться одновременно, взглянув на конфигурации по умолчанию, поэтому вы можете настроить множество таких параметров моментальных снимков rdb.
Журнал АОФ
Вы должны догадаться по названию.Этот режим сохранения осуществляется с использованием журналов.Режим aof работает путем преобразования каждой инструкциидобавитьв файл журнала (файл appendonly.aof по умолчанию), при перезапуске Redis восстановление набора данных достигается путем воспроизведения операций в файле журнала aof.
После открытия постоянного режима AOF Redis получит всеИзменить командуДобавить в файл журнала с помощью функции записи.Конкретное выполнение может быть установлено для следующих трех типов:
- всегда: принудительная запись каждый раз, когда выполняется операция модификации
- Everysec: принудительная запись каждую секунду (рекомендуется)
- нет: не сохранять активно, хранить данные в операционной системе, обычно linux обновляет данные каждые 30 минут
Эти три режима соответствуютappendfsync always,appendfsync everysec,а такжеappendfsync no
Затем мы можем взглянуть на содержимое журнала aof, вот небольшой фрагмент протестированного мной файла aof:
set
$3
bbb
$3
aaa
*3
$3
set
$3
aaa
$3
ccc
*2
$3
del
$3
aaa
Видно, что все команды модификации проходят через命令符-数据库名-key值Этот порядок сохраняется, и читабельность тоже очень высокая.
Но есть еще проблема с логом aof, если мы будем повторно выполнять операцию set, то эти ненужные операции будут неоднократно сохраняться в журнале aof, потому что конечный результат выполнения этих команд ничем не отличается от результата выполнения команды set , то Как решить эту проблему избыточности данных?
На самом деле, об этом подумали и разработчики Redis. Redis предоставляет команду bgrewriteaof. Сервер Redis, получивший эту команду, автоматически разветвит дочерний процесс. Этот дочерний процесс создаст снимок данных для восстановления текущих данных. Когда запись будет завершена, дочерний процесс отправит сигнал родительскому процессу, а затем родительский процесс также запишет команды модификации из кеша в этот временный файл и использует этот временный файл для замены исходного файла aof.
В этом сгенерированном файле aof вы обнаружите, что выполняются почти все операции установки, и в основном нет команды установки, которая повторяет значение, поэтому восстановление происходит довольно быстро.
Преимущества шаблона aof заключаются в следующем:
- Читабельность очень высокая.Если происходит неправильная операция, вы можете скопировать файл журнала aof перед операцией перезаписи, удалить неправильную операцию, а затем заменить исходный файл, что не влияет на восстановление и чтение Redis.Вы можете использовать для экстренных случаев восстановление
- Вероятность потери данных очень низкая, даже если они будут потеряны, это не окажет большого влияния (если вы установите резервное копирование каждую секунду, вы потеряете данные, записанные в течение максимум 1 с)
Но есть еще недостатки:
- файлы aof обычно больше, чем файлы rbd
- В зависимости от выбранной стратегии fsync, aof может быть медленнее, чем rdb.
- При большой нагрузке на запись aof не может гарантировать максимальную задержку, в то время как rbd может
- Есть вероятность ошибок, которые не могут полностью восстановить данные Redis
сцены, которые будут использоваться
При обычном использовании мы не можем сказать, что лучше, но мы должны выбирать в соответствии с реальной ситуацией.Здесь я даю несколько советов по выбору:
- Если вы можете допустить несколько минут потери данных в случае простоя, используйте режим моментальных снимков RDB, который позволяет быстрее перезапустить Redis.
- В остальных случаях рекомендуется режим RDB+AOF.
Да, вы можете настроить режимы rdb и aof одновременно, Redis официально рекомендует это делать: Aof — основной режим, rdb — вспомогательный, aof записывает логи, rdb делает резервную копию базы данных и заменяет движок aof после сбоя .
Суммировать
Объяснение постоянства в основном здесь. Здесь просто краткое введение в содержание постоянства redis. Часть этой статьи предназначена для личного понимания, обобщения и практики, а часть предназначена для справки.Постоянство Redis — RedisЭтот официальный документ, если есть какие-либо ошибки, пожалуйста, поправьте меня