Все технические номера галантереи: Эта статья была включена в github, добро пожаловать на звездочку/форк:GitHub.com/wasabi1234/…

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

1 Введение в настойчивость

1.1 Что такое настойчивость

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

Например, если ваш Redis не работает, вам нужно сделать Redis доступным как можно скорее!

Перезапустите Redis и позвольте ему предоставлять услуги внешнему миру как можно скорее. Если вы не сделаете резервную копию данных, даже если Redis запущен, данные исчезнут! Что вы можете использовать?

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

MySQL не работает, и вы не можете найти данные для восстановления в Redis. Откуда берутся данные Redis? Это из MySQL!

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

1.2 Метод персистентности

Redis предоставляет два метода сохранения:

Redis RDB — моментальный снимок

Выполнение снимков набора данных на определенный момент времени с заданными интервалами, аналогично файлу frm MySQL Dump.

Redis AOF — журнал команд

AOF записывает каждую операцию записи, полученную сервером, которая снова выполняется при запуске сервера для восстановления исходного набора данных. Команды регистрируются в том же формате, что и сам протокол Redis, и принимают толькоappend-onlyСпособ. Если журнал слишком велик, Redis может перезаписать журнал в фоновом режиме. Подобно MySQL Binlog, Hbase HLog. При перезапуске Redis все данные восстанавливаются путем воспроизведения инструкций записи в журнале.

Если вы хотите, чтобы Redis использовался только как чистый кеш памяти, вы также можете отключить RDB и AOF.

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

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

2 RDB - полная запись

KV, хранящийся сервером Redis в нескольких БД, можно понимать как состояние Redis. когда это произойдет写操作, Redis переключится из одного состояния в другое. Полномасштабное сохранение — это сохранение всех данных Redis на жестком диске в определенный момент для формирования моментального снимка. Когда Redis перезапускается, Redis можно восстановить до последнего постоянного состояния, загрузив последние данные моментального снимка.

2.1 Метод триггера

save

save может запускаться на дисплее клиента или при завершении работы Redis. спасти себя单线程串行Поэтому, когда объем данных велик, сервер Redis может зависнуть на долгое время. Однако в течение периода резервного копирования никакие другие команды выполняться не будут, поэтому период резервного копирования数据的状态始终是一致性из.

Если есть старый файл RDB, новый заменит старый, а временная сложность будет O(N).

bgsave

bgsave также может быть

Явно инициируется клиентом
Настройка запуска задач по времени
Инициируется подчиненными узлами в архитектуре ведущий-подчиненный

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

Для bgsave после того, как родительский процесс разветвит дочерний процесс, асинхронная задача будет当前的内存状态作为一个版本进行复制. Изменения, внесенные в процессе репликации, не будут отражены в этой резервной копии.

Вместо команд используйте конфигурацию

В конфигурации Redis по умолчанию при выполнении любого из следующих условий выполнение bgsave запускается автоматически:

настроить	seconds	changes
save	900	1
save	300	10
save	60	10000

Преимущество bgsave перед save异步执行, не влияет на последующее выполнение команды. Но разветвление дочернего процесса, которое включает копирование памяти родительского процесса, увеличит нагрузку на память сервера.当内存开销高到使用虚拟内存时，bgsave的Fork子进程会阻塞运行, что может привести к недоступности второго уровня. Поэтому при использовании bgsave необходимо убедиться, что на сервере достаточно свободной памяти.

Заказ	save	bgsave
Тип ввода-вывода	Синхронизировать	асинхронный
блокировать ли	блокировать	неблокирующий (блокирующий на форке)
сложность	O(N)	O(N)
преимущество	Не потребляет дополнительную память	Не блокировать клиентские команды
недостаток	Блокировать клиентские команды	Необходимо разветвить дочерний процесс, накладные расходы памяти велики

Оптимальная конфигурация РБД

Отключите автоматический RDB:

dbfilename dump-${port}.rdb
dir /redisDataPath
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

Время срабатывания, требующее внимания

Для полной репликации по времени репликации master-slave главный узел выполнит bgsave.
debug reload
shutdown
флешдб, флешвсе

свойства РБД

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

Преимущества RDB

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

Недостатки РБД

Время, O(n)
fork(): потребление памяти, стратегия копирования при записи

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

Неуправляемый, легко потерять данные

Как правило, RDB создается каждые 5 минут или дольше. Если Redis выйдет из строя во время процесса, данные, которые не сохранялись в последнее время, будут потеряны.

2.2 Процесс восстановления

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

3 AOF (добавлять только файл) — инкрементальный режим

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

Его файл создается следующим образом:

Но этот режим по умолчанию выключен и его нужно включать вручную

3.1 Процесс записи

Три стратегии AOF

always

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

every second

Асинхронно запускает синхронную операцию каждую секунду.

no

ОС решает, когда синхронизироваться Таким образом, Redis не может решить, когда приземлиться, поэтому он неуправляем.

В сравнении

Заказ	always	everysec	no
преимущество	без потери данных	1 fsync/с, потеря данных за 1 с	По умолчанию, не нужно устанавливать
недостаток	Накладные расходы ввода-вывода высоки, а общий STAT-диск имеет всего несколько сотен TPS.	Потерять данные 1s	Не могу контролировать

3.2 Процесс воспроизведения

Время воспроизведения AOF также机器启动时,一旦存在AOF，Redis就会选择增量回放.

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

Оптимизирована перезапись режима AOF.

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

Родной АОФ

set hello world
set hello java
set hello hehe
incr counter
incr counter
rpush mylist a
rpush mylist b
rpush mylist c
过期数据

AOF переписать

set hello hehe
set counter 2 
rpush mylist a b c

Роль переписывания AOF

Уменьшить использование жесткого диска
Ускорить восстановление

3.3 Есть два способа переписать AOF

bgrewriteaof

Конфигурация перезаписи AOF

элемент конфигурации

Скорость роста файла AOF / размер файла AOF, необходимый для перезаписи

Текущий размер AOF (единица измерения: байты)

aof_base_sizeРазмер последней загрузки и перезаписи AOF (единица измерения: байты)

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

aof_current_size > auto-aof-rewrite-min-size
aof_current_size - aof_base_size/aof_base_size > auto-aof-rewrite-percentage

3.4 Процесс перезаписи AOF

Конфигурация перезаписи AOF

Изменить файл конфигурации

appendonly yes
appendfilename "appendonly-$(port).aof"
appendfsync everysec
dir /opt/soft/redis/data
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
no-appendfsync-on-rewrite yes

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

Лучше избежать потери данных

Как правило, AOF выполняет fsync через подпроцесс каждую 1 с и теряет данные до 1 с.

append-onlyрежим добавления записи

Таким образом, нет накладных расходов на адресацию диска, высокая производительность записи, и файл нелегко повредить, даже если конец файла поврежден, его легко восстановить.

Даже если файл журнала слишком велик и выполняется фоновая операция перезаписи, это не повлияет на чтение и запись клиента.

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

Команды записываются в очень читаемом виде

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

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

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

Более сложный метод, основанный на журнале команд/объединении/воспроизведении, такой как AOF, более хрупок, чем метод на основе RDB, который каждый раз сохраняет полный моментальный снимок данных, и подвержен ошибкам. Тем не менее, AOF предназначен для предотвращения ошибок, вызванных процессом перезаписи, поэтому каждая перезапись основана не на старом журнале инструкций для слияния, а на данных в памяти в то время для перестроения инструкций, чтобы надежность была лучше. .

4 Выбор и лучшие практики

Заказ	RDB	AOF
приоритет загрузки	Низкий	высокий
объем	Низкий	высокий
скорость восстановления	быстрый	медленный
безопасность данных	потерянные данные	Определяется стратегией
величина	тяжелый вес	легкий

Оптимизация Redis 4.0 для механизма сохраняемости

Redis 4.0 начал поддерживать смешанное сохранение RDB и AOF (по умолчанию отключено, можно настроить через элементы конфигурацииaof-use-rdb-preambleна).

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

4.1 Лучшая стратегия RDB

закрытие
Централизованное управление RDB руководство по эксплуатации
Включите конфигурацию автоматического выполнения на ведомом узле, но часто выполнять RDB нецелесообразно.

4.2 Лучшие стратегии AOF

Его рекомендуется открывать, но если он используется только как тайник, открывать его не обязательно.
AOF переписывает централизованное управление
everysec

4.3 Выберите RDB и AOF

Не используйте только RDB, так как это приведет к потере большого количества данных.
Также не просто использовать AOF, потому что тогда есть две проблемы
- Если вы используете AOF для холодного резервного копирования без RDB для холодного резервного копирования, скорость восстановления выше.
- RDB каждый раз генерирует моментальные снимки данных просто и грубо, что является более надежным и позволяет избежать ошибок в сложном механизме резервного копирования и восстановления AOF.
Совместное использование AOF и RDB
- Используйте AOF, чтобы гарантировать, что данные не будут потеряны, как лучший выбор для восстановления данных.
- Используйте RDB для различных степеней холодного резервного копирования.Когда файлы AOF потеряны или повреждены, вы также можете использовать RDB для быстрого восстановления данных.

4.4 Некоторые рекомендации

Щепка

Например, установите параметр maxmemory, чтобы каждый редис хранил только 4 ГБ пространства, чтобы различные операции не были слишком медленными.

Мониторинг (жесткий диск, память, нагрузка, сеть)
достаточно памяти

Ссылаться на

Redis.IO/topics/пирсинг…
«Проектирование и реализация Redis»