1. Предисловие
В последнее время Redis используется в качестве кэша в проекте для облегчения обмена данными между несколькими бизнес-процессами. Поскольку данные Redis хранятся в памяти, если сохранение не настроено, все данные будут потеряны после перезагрузки Redis, поэтому нужно включить функцию сохранения Redis для сохранения данных на диске, и при перезагрузке Redis можно восстановить данные с диска. Redis предлагает два способа сохранения: сохранение RDB (принцип — сбросить записи базы данных Reids в память в RDB persistence на диске) и другой — сохранять AOF (принцип заключается в записи журналов операций Reids в файл в виде приложения). Так в чём же разница между этими двумя методами устойчивости и как их изменить? Большинство материалов, которые я читал в Интернете, посвящены тому, как настраивать и использовать эти два метода, но нет никакого введения в разницу между ними и о том, в каких приложениях стоит использовать.
2. Разница между ними
Персистентность RDB означает запись снимка набора данных в памяти на диск в течение определённого временного интервала, а фактический процесс — форк подпроцесса, сначала запись набора данных в временный файл, затем замена предыдущего файла после успешной записи и сохранение его с помощью бинарного сжатия.
AOF сохраняет каждую операцию записи и удаления, выполненную сервером в виде журнала, и операция запроса не будет записываться, а записывается в тексте, и вы можете открыть файл, чтобы увидеть подробную запись операции.
3. Преимущества и недостатки этих двух вариантов
Каковы преимущества RDB?
1). После этого вся база данных Redis будет содержать только один файл, что идеально подходит для резервных копий файлов. Например, вы можете захотеть архивировать последние 24 часа каждый час, а также архивировать последние 30 дней каждый день. С такой резервной стратегией мы легко сможем восстановиться в случае катастрофического отказа системы.
2). RDB — очень хороший выбор для восстановления после катастроф. Потому что мы можем легко сжать один файл и перенести его на другой носитель.
3). Максимизировать производительность. Для сервисного процесса Redis единственное, что нужно сделать при запуске сохранения — это выделить дочерние процессы, после чего дочерние процессы выполнят эти задачи, что значительно позволяет избежать выполнения IO-операций сервисным процессом.
4). По сравнению с механизмом AOF, при большом наборе данных эффективность запуска RDB будет выше.
В чём есть недостатки RDB?
1). Если вы хотите обеспечить высокую доступность данных, то есть максимально избежать потери данных, то RDB не будет хорошим выбором. Потому что как только система выходит из строя до запланированного сохранения, данные, ранее записанные на диск, будут потеряны.
2). Поскольку RDB способствует сохранению данных через форк-подпроцессы, если набор данных большой, это может привести к тому, что весь сервер останавливается на сотни миллисекунд или даже на одну секунду.
Каковы преимущества AOF?
1). Этот механизм может обеспечить большую безопасность данных, то есть сохранять данные. В Redis предусмотрены три стратегии синхронизации: синхронизация в секунду, синхронизация по модификации и десинхронизация. На самом деле, синхронизация в секунду также выполняется асинхронно, и её эффективность тоже очень высока, но разница в том, что когда система выходит из строя, изменённые данные теряются в течение этой секунды. И каждый раз, когда модификация синхронизируется, мы можем представить это как сохранение синхронизации, то есть каждое изменение данных немедленно записывается на диск. Можно предвидеть, что этот метод наименее эффективен. Что касается отсутствия синхронизации, больше не нужно объяснять, думаю, все правильно понимают.
2). Поскольку механизм использует режим добавления для записи лог-файлов, даже если в процессе записи возникает простой, содержимое, уже существующее в файле журнала, не будет уничтожено. Однако, если мы запишем только половину данных, и система на этот раз вылетит, не волнуйтесь, мы можем использовать инструмент redis-check-aof, чтобы решить проблему согласованности данных до следующего запуска Redis.
3). Если журнал слишком большой, Redis может автоматически включить механизм переписывания. То есть Redis непрерывно записывает данные модификации в старый файл диска в режиме добавления, а также создаёт новый файл для записи, какие команды изменения выполняются в этот период. Таким образом, безопасность данных может быть лучше гарантирована при переключении между перезаписями.
4). AOF содержит понятный, легко понимаемый файл журнала, который фиксирует все изменения. На самом деле, мы также можем завершить реконструкцию данных с помощью этого файла.
В чём есть недостатки OV?
1). Для того же количества наборов данных файлы OF обычно больше файлов RDB. RDB восстанавливает большие наборы данных быстрее, чем AOF.
2). В зависимости от стратегии синхронизации, AOF, как правило, медленнее RDB по эффективности работы. Короче говоря, эффективность политики синхронизации в секунду относительно высока, а эффективность политики синхронного отключения столь же эффективна, как у RDB.
Критерии выбора этих двух вариантов — готова ли система пожертвовать частью производительности ради более высокой согласованности кэша (AOF), или же она готова не включать резервные копии в обмен на более высокие показатели при частых операциях записи, а затем делать резервные копирования (RDB) при ручном запуске Сохранения. RDB имеет более окончательное и последовательное значение. Однако производственная среда — это скорее сочетание этих двух вариантов.
4. Распространённые конфигурации
Конфигурация сохранения RDB
Redis загружает снимок набора данных в файл dump.rdb. Кроме того, мы можем изменять частоту дампов сервера Redis через конфигурационный файл; после открытия файла 6379.conf мы ищем save, и видим следующую информацию о конфигурации:
Персистентная конфигурация AOF
Существует три способа синхронизации в профиле Redis:
Полная конфигурация:
В тестовой директории будет создан новый файл "appendonly.aof" следующим образом:
|
Опубликовано 04.02.2021 13:47:27
|
|
|
|
Хозяин|
Опубликовано 08.02.2021 11:45:25
|
Опубликовано 22.09.2021 20:26:16