В прошлой статье мы говорили о стратегии постоянного хранения RDB, основанной на моментальных снимках памяти Redis, По сути, это позволяет redis разветвить дочерний процесс для обхода словарей во всех наших базах данных и записи файлов на диск.
Но на самом деле у этого метода есть свои недостатки, не говоря уже о том, что блокирующий вызов сохранения заблокирует весь сервис redis, даже асинхронный bgsave основан на временном интервале и том, сколько операций обновления запускается каждые несколько секунд перед генерацией RDB. файл, то если после создания второй RDB, сразу после того, как служба выйдет из строя, по крайней мере несколько секунд или более данных будут потеряны, и эти данные будут безвозвратно утеряны.
AOF — это еще одна стратегия сохранения данных в Redis, основанная на журналах операций и также являющаяся отличной стратегией сохранения, но, конечно, у нее есть и недостатки. Итак, в этой статье речь пойдет об этой стратегии постоянства AOF.
1. Что такое стратегия постоянства AOF
AOF означает добавление только файла.Когда Redis принимает эту стратегию сохранения данных, всякий раз, когда сервер Redis получает команду обновления, команда будет добавлена в буфер памяти aof после операции и обновлена в определенное время.Буфер на диск файл, который наш файл aof.
В файле конфигурации запуска Redis по умолчанию будет две конфигурации:
appendonlyУказывает, включает ли redis стратегию сохраняемости AOF,appendfilenameУказывает имя сгенерированного файла AOF.
Вы также можете указать для параметра appendonly значение yes, а затем выполнить команду set, чтобы увидеть, создается ли файл appendonly.aof в корневом каталоге Redis.
Также в redis.confappendfsyncТакая конфигурация указывает частоту записи файла AOF.Даже если файловый ввод-вывод в Linux использует эффективный epoll, слишком неэффективно и ненужно выполнять файловый ввод-вывод каждый раз, когда получена команда обновления.
Элемент конфигурации appendfsync имеет следующие три значения:
- всегда: обновлять кэш каждый раз, когда вызывается системная функция serverCorn.
- каждую секунду: выполнять запись на диск каждую секунду, в течение которой все команды будут храниться в буфере aof
- no: нет контроля, пусть операционная система решает, когда очищать буфер
Конфигурация Redis по умолчанию — каждую секунду, то есть область кеша обновляется каждую секунду.
2. Переписать AOF
Следовательно, теоретически, по мере того, как сервер redis продолжает работать, сгенерированные файлы aof будут становиться все больше и больше, а redis предоставляет стратегию перезаписи AOF, помогающую оптимизировать и сжимать файлы aof.
Например:
set a "a"
set b "b"
set c "c"
del a
del b
При нормальных обстоятельствах журнал пяти команд будет сохранен в файле aof, а затем данные могут быть выполнены последовательно при восстановлении данных. И когда вы начинаете перезаписывать AOF, на самом деле наш файл aof содержит толькоset c "c"лог этой команды.
Это всего лишь простой пример, но на самом деле эффективность перезаписи AOF намного выше: часто сотни или даже тысячи журналов команд переписываются в однозначные числа. Наиболее очевидным преимуществом для нас является то, что размер файла aof становится меньше, а скорость восстановления данных увеличивается.
Вообще говоря, мы можем заставить сервер перезаписать файл aof, отправив команду bgrewriteaof на сервер Redis.Если в настоящее время выполняются подпроцессы перезаписи, эта перезапись будет отложена, в противном случае перезапись будет запущена напрямую.
Кроме того, мы также можем настроить размер файла aof в файле конфигурации, чтобы автоматически запускать перезапись файла.
Поскольку перезапись файлов aof также обрабатывается подпроцессами ответвления и обрабатывается подпроцессами, основной процесс по-прежнему предоставляет услуги, поэтому Redis также предоставляет буфер перезаписи.Когда обнаруживается, что подпроцесс перезаписывает файл aof, последняя команда запроса будет он не только добавляется в буфер AOF, но и будет добавлен в буфер перезаписи AOF.Когда дочерний процесс завершает задачу перезаписи, основной процессблокировкаДобавьте журнал команд буфера перезаписи в последний файл aof.
посмотрите несколько конфигураций
no-appendfsync-on-rewriteНастраивает, должен ли сервер redis записывать команду aof в буфер на диск, когда сервер redis собирается заблокироваться из-за определенных условий (например, сохранения), настройте yes, чтобы сбрасывать кеш на диск каждый раз, когда встречается блокирующая операция, и нет необходимости его настраивать. Что касается того, заблокирован ли сервер или нет, кэшированная команда находится в области кэша.
auto-aof-rewrite-percentageНастройте, когда процент размера файла aof по сравнению с размером файла aof предыдущей версии вызывает перезапись AOF. Например, параметр auto-aof-rewrite-percentage настроен на 100, а размер файла aof предыдущей версии равен 100M, затем, когда наш файл aof достигает 200M, запускается перезапись AOF.
auto-aof-rewite-min-sizeНастроен минимально допустимый размер файла aof, за пределами этого размера необходимо выполнить перезапись AOF.
3. РБД и АОФ
RDB основан на моментальных снимках памяти.Есть два способа сохранения и bgsave.Первый заблокирует службу Redis, а второй представляет собой асинхронный дочерний процесс fork, который не влияет на основной процесс предоставления услуг. В большинстве случаев мы запускаем запись файла RDB, настроив интервал. Файл RDB сохраняет моментальный снимок всех данных в памяти Redis.
Преимущество:
- При том же объеме данных файл rdb меньше файла aof, а скорость восстановления выше, чем у файла aof.
- Файл rdb представляет собой полную резервную копию всех данных, а хранилище данных компактно, даже с разными версиями redis его можно восстановить без проблем.
- Чтобы сохранить весь rdb, вам нужно только разветвить дочерний процесс для сохранения, родительский процесс по-прежнему может предоставлять услуги, а эффективность максимальна.
слабость это:
- Легко потерять данные, даже если настроено резервное копирование триггера времени события, по крайней мере одна секунда данных будет потеряна
- Если объем данных слишком велик, дочерний процесс форка будет блокировать миллисекундное время.
AOF основан на журнале выполнения команды.Каждая команда обновления будет сброшена в буферную область, а затем записана в файл aof на диске в определенный момент времени.
Преимущество:
- По сравнению с RDB данные AOF более надежны, и данные теряются на срок до одной секунды.
- Отказоустойчивость базы данных стала лучше, а некоторые неверные операции можно откатить, напрямую изменив файл aof
слабость это:
- Файлы AOF обычно большие, а эффективность восстановления ниже, чем у RDB, поэтому они не подходят для холодного резервного копирования данных.
В целом стратегия AOF сделает данные более стабильными и обеспечит более полное резервное копирование данных. RDB обладает высокой эффективностью восстановления и подходит для аварийного восстановления. Рекомендуется включить оба варианта в производственной среде.
PS: Redis официально заявляет, что в будущем будет выпущена новая стратегия сохранения, объединяющая RDB и AOF для обеспечения более эффективного сохранения данных, и мы с нетерпением ждем этого.