Это первый день, когда я участвовал в вызове Gengwen. Проверьте детали события:Обновить вызов

Статья была впервые опубликована в публичном аккаунте:Грибы не могут спать, добро пожаловать посмотреть

предисловие

Redis — это форма хранения пар ключ-значение.Все ключи строкового типа, а значения имеют множество типов, таких как строка, список, хэш, набор, отсортированный набор и другие типы. При настройке пары ключ-значение мы также должны установить для нее время истечения срока действия с помощью команд expire и pexpire, его также можно установить с помощью команды setnx. Итак, после установки срока действия, как удалить пару ключ-значение с истекшим сроком действия? Если вы хотите узнать ответ, давайте посмотримСтратегия удаления ключей с истекшим сроком действия для Redis.
Прежде чем говорить о стратегии удаления, есть смысл сначала сообщить вам, то есть, если вы определяете, истек ли срок действия ключа, здесь я резюмирую:

1. Проверить, есть ли ключ в словаре срока действия, если он существует, получить время истечения срока действия ключа. (Словарь истечения хранит время истечения срока действия каждого ключа, ключ в словаре — это ключ, а значение — время истечения срока действия длинного типа)
2. Получив время истечения срока действия, сравните его с текущей отметкой времени UNIX, если оно больше, срок действия ключа истечет.

Выше приведен метод определения того, истек ли срок действия ключа. Далее поговорим о том, как удалить ключ по истечении срока его действия.

В настоящее время существует три стратегии удаления:

• Удаление по времени: при установке срока действия ключа создайте таймер и используйте таймер для удаления ключа по истечении срока действия ключа..
• Ленивое удаление: Ленивое удаление не удаляется по истечении времени истечения срока действия, но каждый раз, когда ключ получен, он будет определять, истек ли срок его действия, если срок его действия истек, удалить его и вернуть пустым; если срок его действия не истек, вернуть ключ стоимость.
• Периодическое удаление: Через регулярные промежутки времени ключи в базе данных проверяются и удаляются, если они устарели. Что касается того, сколько и когда удалять, это определяется с помощью специальных процедур..

Каждая стратегия удаления подробно описана ниже.

Регулярно удалять

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

ленивое удаление

Преимущества стратегии ленивого удаления: экономия процессорного времени. Программа будет решать, следует ли удалять ключ, только когда ключ удален, и она действует только на текущий ключ, а для обработки других ключей с истекшим сроком действия не требуется время процессора.
Недостатки стратегии ленивого удаления: не экономит память. Потому что ключ проверяется на удаление только при его использовании.Если есть большое количество неиспользованных ключей, то эти ключи не будут удалены даже по истечении срока их действия, и всегда будут занимать память. Это можно понимать как утечку памяти — много бесполезных данных всегда занимает память и не будет удалено.

регулярно удалять

Сравнение времени удаления недружественного ЦП, инертное удаление недружественной памяти. Регулярно удаляйте компромисс:

• Стратегия периодического удаления выполняет удаление ключей с истекшим сроком действия через регулярные промежутки времени и уменьшает влияние удаления на время ЦП, ограничивая продолжительность и частоту удаления.
• Более того, регулярно удаляя ключи с истекшим сроком действия, потери памяти, вызванные ключами с истекшим сроком действия, эффективно сокращаются.

Однако продолжительность и частоту удалений трудно определить, потому что:

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

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

На самом деле Redis использует стратегию ленивого удаления + регулярного удаления.

Этими двумя способами вы можете эффективно использовать процессорное время и избежать потери памяти. Далее поговорим о реализации ленивого удаления и периодического удаления.

Реализация стратегии ленивого удаления

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

• Если срок действия ключа истек, ключ удаляется и возвращается null.
• Если срок действия ключа не истек, ничего не делайте.

Реализация периодической политики удаления

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

• При каждом запуске функции из определенного количества ключей базы данных случайным образом выбирается определенное количество ключей для проверки, а ключи с истекшим сроком действия удаляются.
• Есть глобальная переменная current_db, которая записывает ход текущей проверки функции activeExpireCycle, и при следующем выполнении функции обрабатывается ход предыдущей. Например, если текущая функция activeExpireCycle выполняется до 10, скажем, current_db = 10; тогда при следующем выполнении функции извлеките 10 из current_db, чтобы продолжить выполнение.
• current_db = 0, когда проверены все ключи базы данных.

Обработка просроченных ключей функциями AOF, RDB и репликации

Создать RDB-файл

При выполнении команды SAVE или команды BGSAVE для создания нового файла RDB программа проверит ключи в базе данных, и ключи с истекшим сроком действия не будут сохранены в новый файл RDB.
Например: redis содержит три ключа r1, r2, r3, и срок действия r1 истек, тогда программа сохранит только r2 и r3 в файл RDB.
Поэтому ключи с истекшим сроком действия не влияют на новые файлы RDB.

Загрузить RDB-файл

При запуске сервера Redis, если сервер включает функцию RDB, сервер загрузит файл RDB;

• Если сервер работает в режиме master, то при загрузке RDB-файла ключи с истекшим сроком действия будут отфильтрованы и не будут загружены в базу данных Redis.
• При работе в подчиненном режиме ключи будут загружены в базу данных независимо от того, истек ли срок их действия или нет. Однако, поскольку подчиненный сервер будет очищен, когда главный и подчиненный серверы синхронизируют данные, ключ с истекшим сроком действия, вообще говоря, не повлияет на подчиненный сервер.

Запись файла AOF

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

AOF переписать

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

копировать

Когда сервер находится в режиме репликации, удаление просроченных ключей с сервера выполняется главным сервером.

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

Небольшой партнер в области комментариев спросил: Поскольку подчиненный сервер не будет активно удалять ключ с истекшим сроком действия, что, если просроченный ключ подчиненного сервера будет запрошен?
Это хороший вопрос, и я пропустил его, когда писал статью.Далее я процитирую отрывок с официального сайта Redis, чтобы объяснить эту проблему.

Просто переведите:
1. Ведомый сервер не истечет срок действия ключа, он будет ждать, пока истечет срок действия ключа у мастера, когда у мастера истечет срок действия ключа (или выселение из-за алгоритма LRU), он сгенерирует команду DEL и отправит ее всем подчиненные серверы.
2. Однако, поскольку срок действия ключа управляется главным устройством, главный сервер не может вовремя предоставить команду DEL, что приводит к тому, что некоторые подчиненные серверы иногда имеют в памяти логически просроченные ключи.Чтобы решить эту проблему, подчиненный использует свои логические часы для отчета Ключ существует только в операциях чтения, которые не нарушают консистентность набора данных (приходит новая команда от хоста) (это немного сложно, вероятно, имеется в виду запись ключа, срок действия которого должен истечь, или ожидание для основной команды DEL через логические часы). Таким образом, ведомое устройство избегает возврата просроченного ключа. На практике кэш страницы HTML, который масштабируется из кэша узла, позволяет избежать проблемы несвоевременного истечения срока действия.

наконец

Стратегия удаления просроченных ключей Redis — это ленивое удаление + обычное удаление, что может разумно контролировать использование ЦП и сократить потери памяти.

Для получения дополнительных знаний по Java и обмена вопросами вы можете зайти в публичный аккаунтГрибы не могут спатьСлушай, давай учиться вместе.

Чем активнее вы будете, тем активнее вы будете. Увидимся в следующий раз~