Сохранение автономной базы данных Redis и создание и удаление с истекшим сроком действия

Кратко

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

Структура хранилища Redis

Во-первых, давайте взглянем на структуру хранилища redis (не много ерунды, чуть выше)

Эта картинка является хорошей иллюстрацией того, как хранится Redis. Мы знаем, что Redis хранит данные в виде пар ключ-значение. Во-первых, Redis будет поддерживать таблицу ключей, в которой хранятся все «ключи» Redis ( То есть, прямая таблица), а затем указать на соответствующее «значение» в виде указателя, и его значение имеет богатую структуру данных, такую как динамические строки, связанные списки, таблицы переходов и т. д., Redis использует хранилище объектов, и каждый key хранится в виде объекта String, а value — в объекте, соответствующем структуре данных.

1. Автономная база данных Redis и стратегия удаления ключей с истекшим сроком действия

Давайте обратимся к теме, стратегия удаления ключей с истекшим сроком действия в redis. Мы знаем, что когда мы устанавливаем redis, по умолчанию он имеет 16 подбаз данных. Мы можем вставлять и удалять пары ключ-значение с помощью некоторых команд, а также мы можем переключать базы данных , но мы обсудим сегодня. Дело не в этом. В redis есть особый вид пары ключ-значение, то есть пара ключ-значение, время истечения которой задается командой expire. указанное время. Наиболее распространенным примером применения является код подтверждения. В жизни нам часто нужны коды подтверждения, срок действия которых обычно истекает через одну минуту. Так что же делать с этими недействительными кодами подтверждения? Если мы оставим это в покое, мы знаем, что Redis локальная база данных.Если мы их не обработаем, то эти проверочные коды будут долго храниться в памяти.Это приведет к утечкам памяти, и со временем сервер неизбежно будет парализован.

1.1 Как Redis хранит просроченные ключи

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

1.2 Как же Redis обрабатывает ключи с истекшим сроком действия?

Не говорите глупостей, просто дайте ответ прямо Три стратегии удаления ключей с истекшим сроком действия для Redis

Регулярно удалять При установке пары ключ-значение со сроком действия добавьте таймер к паре ключ-значение и удалите пару ключ-значение, когда наступит время истечения срока действия. преимущество хорошая своевременность недостаток Очень недружелюбен к процессору, потребляет много ресурсов процессора и влияет на общую производительность.
ленивое удаление Пусть ключ с истекшим сроком действия игнорируется, но каждый раз, когда redis извлекает пару ключ-значение, выполняется проверка срока действия, и ключ с истекшим сроком действия удаляется. преимущество очень дружелюбный к процессору недостаток Очень недружественный к памяти, вызывает много утечек памяти
регулярно удалять Время от времени проверяйте базу данных и удаляйте в ней просроченные ключи, а сколько баз проверять, то это определяется алгоритмом преимущество Дружественный к процессору и памяти недостаток Если он очищается часто, он не дружественный к процессору, а если он не очищается вовремя, он не дружественный к памяти.

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

2. Постоянство Redis

2.1. РБД

Метод персистентности RDB заключается в сохранении текущего состояния данных, то есть в сохранении пары ключ-значение в виде сжатого двоичного файла.Существуют две команды для персистентности RDB.

СПАСТИ Система блокирует, а затем создает файл RDB и не может предоставлять внешние службы в течение периода создания файла.
BGSСОХРАНИТЬ Создайте дочерний процесс для создания файлов RDB, а родительский процесс продолжит обработку задач.

Итак, когда RDB сохраняет текущее состояние? Следующие ситуации в Redis сохранят текущее состояние в RDB (конфигурация по умолчанию).

1. Есть модификация в течение 900 секунд, которая сохраняется в RDB
2. Если есть десять модификаций в течение 300 секунд, сохраните RDB
3. 10 000 модификаций в течение 60 секунд, и RDB сохраняется.

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

2.2. АОФ

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

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

1. Записать команду в буфер aof aof_buf Мы знаем, что запись в память — чрезвычайно трудоемкая операция, поэтому, чтобы ускорить скорость обратной записи и уменьшить потери производительности, вызванные вводом-выводом, Redis добавляет буфер.
2. Запишите команду буфера в файл AOF для синхронизации. Функция FlushAppendOnlyFile используется для записи данных из буфера обратно в AOF-файл, и выполнение этой функции фактически определяется опцией конфигурации appendSync в Redis.У него есть три стратегии.
- awalys всегда синхронизирует данные в буфере aof_buf с файлом AOF (этот метод потребляет много операций ввода-вывода и ЦП)
- Everysec записывает данные каждую секунду (Redis по умолчанию)
- нет Синхронизация данных в буфере aof_buf с файлом AOF определяется системой.
Из вышеприведенного введения мы видим, что эти три метода имеют свои преимущества и недостатки, и система использует метод Everysec.
3. Перезапись файлов AOF Когда файл AOF слишком велик, это повлияет на Redis, а затем Redis перезапишет AOF. Такие как
```
//假设系统有如下三条命令
127.0.0.1:6379[1]> RPUSH list 1 2 3 4    //[1,2,3,4]
127.0.0.1:6379[1]> RPOP list                    //[1,2,3]
127.0.0.1:6379[1]> LPOP list            //[2,3]

//其实可用一条命令代替
RPUSH 2，3
```
Переписано, чтобы значительно уменьшить размер файлов Redis AOF.
4. Когда включен файл AOF? Файл AOF также автоматически загружается в файл AOF для синхронизации при запуске системы.

2.3 Процесс запуска при сосуществовании AOF и RDB

Смотри ниже

2.4, некоторые вещи стоит обсудить

Мы знаем, что Redis — это база данных в памяти, а не постоянная база данных.Согласно теории CAP, Redis — это база данных, которая удовлетворяет требованиям высокой доступности и отказоустойчивости разделов.На самом деле, постоянство Redis небезопасно? Ответ действительно тот же.Многие говорят, что Redis тоже может быть персистентным.Разве не достаточно установить стратегию персистентности AOF на ожидание, тогда максимум одна команда будет потеряна. . .

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

У вас не может быть обоих, поэтому Redis не является хорошим инструментом постоянной базы данных.При сохранении важных данных вам все равно придется использовать инструменты постоянной базы данных, такие как mysql sqlsever.

Эпилог

Текст кратко представляет некоторое простое содержание Redis. Если есть какие-либо ошибки, добро пожаловать для обсуждения и внесения комментариев и предложений, пожалуйста, проявите милосердие. В следующей статье этот небольшой редактор кратко представит многомашинную версию кластера Redis, кластер синхронизация и т.д., будем рады видеть вас в следующий раз.

Справочник «Проектирование и внедрение Redis»
Интернет-статьи, а не перечисленные одна за другой.

Цзэнсинь

Команда разработчиков Java компании Guangzhou Reed Technology

Reed Technology-Guangzhou Professional Internet Software Service Company

Ухватитесь за каждую деталь и создайте каждую красоту

Подпишитесь на наш официальный аккаунт, чтобы узнать больше

Хотите сразиться с нами? лагу поиск"Рид Технология» или отправить свое резюме наserver@talkmoney.cnПрисоединяйтесь к нам

Следите за нами, ваши комментарии и лайки - наша самая большая поддержка