Redis — это продвинутая база данных с ключевыми значениями. Это похоже на memcached, но данные можно сохранять, а типы данных богаты. Существуют строки, связанные списки, множества и упорядоченные коллекции. Он поддерживает вычисление суммирования, пересечения и дополнения (разницы) коллекций на серверной стороне, а также различных функций сортировки. Таким образом, Redis также можно рассматривать как сервер структур данных.
Все данные Redis хранятся в памяти, а затем асинхронно хранятся на диске время от времени (это называется «полуперсистентным режимом»); Вы также можете записывать каждое изменение данных в файл Append Only (AOF) (это называется «режим полной устойчивости»).
Первый метод — filesnapshotting: по умолчанию redis сохраняет данные на диск в виде снимка (бинарный файл, dump.rdb, можно указать это имя), а формат в конфигурационном файле: save N M означает, что в течение N секунд redis сделает снимок на диск, если в redis произойдёт хотя бы M изменений. Конечно, мы также можем вручную выполнять сохранение или bgsave (асинхронно) для получения снимков.
Вот краткое введение в его работу: когда Redis нужно сохраняться, Redis форкирует дочерний процесс; Дочерний процесс записывает данные в временный RDB-файл на диске; Когда подпроцесс завершает запись временного файла, он заменяет исходный RDB, который обладает преимуществом копирования при записи
Есть также метод сохранения — Append-only:filesnapshotting method. Когда redis ненормально мёртв, недавние данные будут потеряны (количество потерянных данных зависит от конфигурации вашей политики сохранения), поэтому это его главный недостаток: при большом объёме бизнеса потеря данных значительна. Метод только добавления позволяет полностью потерять данные, но производительность Redis хуже. AOF можно сохранять на протяжении всего процесса, его нужно включить только в конфигурационном файле (по умолчанию — нет), приложение только да. После включения AOF каждый раз, когда Redis выполняет команду на изменение данных, они добавляются в файл AOF, а при перезагрузке Redis файл AOF считывается для «воспроизведения» для восстановления до последнего момента перед закрытием Redis.
Перезапись LOG По мере изменения данных AOF-файл становится всё больше и больше, многие из которых записывают изменения в ключе. Поэтому у Redis есть интересная функция: он воссоздаёт файл AOF в фоне, не влияя на работу на стороне клиента. Выполнение команды BGREWRITEAOF в любой момент записывает кратчайшую последовательность команд в текущей памяти на диск, и эти команды могут полностью построить текущую ситуацию с данными без ненужных изменений (таких как изменения состояния, изменения счетчика и т.д.), уменьшая размер файла AOF. Поэтому при использовании OF Redis также рекомендует использовать BGREWRITEAOF.
Существует три способа обновления файла AOF, см. параметр конфигурации appendfsync: appendfsync всегда вызывает fsync для смыва в AOF-файл при каждом запуске команды на изменение, что очень, очень медленно, но при этом очень безопасно; appendfsync everysec вызывает fsync каждую секунду, чтобы быстро смыть в AOF-файл, но может потерять данные в течение секунды; appendfsync no зависит от ОС для обновления, redis не обновляет OV, который самый быстрый, но безопасность слабая. По умолчанию рекомендуется обновление в секунду, чтобы учитывать и скорость, и безопасность.
Возможно, по системным причинам повреждение AOF, redis больше не может загружать этот OF OV, вы можете следовать следующим шагам для исправления: Сначала сделайте резервную копию AOF-файла и скопируйте его в другое место; Исправьте исходный файл OF, выполните: $redis-check-aof –fix; Вы можете использовать команду diff –u, чтобы увидеть, где файлы несогласованы до и после ремонта. Перезапусти сервис Redis.
Как работает LOG Rewrite: То же самое использует копирование при записи: сначала redis форкирует дочерний процесс; Дочерний процесс записывает последний AOF в временный файл; Родительский процесс постепенно записывает последние выполненные изменения в память (на данный момент старый AOF всё ещё записан, и его безопасно переписывать в случае сбоя); Когда дочерний процесс заканчивает перезапись временного файла, родительский процесс получает сигнал и записывает предыдущие инкрементальные изменения в память в конец временного файла. Redis переименовывает старый файл OF, переименовывает временный файл и начинает записывать в новый OF.
Наконец, на всякий случай (если машина вылетит или диск вылетит), не забывайте регулярно делать резервные копии файла *rdb *.aof, сгенерируемый с помощью filesnapshoting или Append-only, на удалённую машину. Я использую crontab для SCP каждые полчаса. Я не использовал функцию мастер-слейв в Redis, потому что получасовая резервная копия должна подойти, и мне кажется, что это небольшая трата времени, если у тебя мастер-слейв. В конечном итоге это зависит от конкретного применения.
|
Опубликовано 24.08.2017 16:37:45
|
|
|
