redis время жизни ключа
Завершение срока действия ключей в Redis
Redis – это открытое in-memory хранилище типа «ключ-значение». По умолчанию ключи Redis постоянные, то есть сервер Redis будет продолжать хранить их до тех пор, пока они не будут удалены вручную. Однако в отдельных ситуациях вы устанавливаете ключ, но знаете, что захотите в дальнейшем удалить его; другими словами, вам нужен непостоянный ключ. В этом мануале мы расскажем, как установить срок действия ключей, проверить, сколько времени остается до истечения этого срока, и отменить все эти настройки.
Как работать с этим мануалом
Это руководство задумано как шпаргалка с примерами. Его не нужно выполнять последовательно – вы можете просто перейти к любому разделу, который имеет отношение к нужной вам задаче.
Команды, использованные в этом мануале, были протестированы на сервере Ubuntu 18.04 и экземпляре Redis версии 4.0.9. Чтобы настроить аналогичную среду, вы можете следовать разделу 1 руководства Установка и защита Redis в Ubuntu 18.04. Мы покажем, как эти ведут себя команды в redis-cli, интерфейсе командной строки Redis. Обратите внимание, что если вы используете другой интерфейс Redis — например, Redli – то вывод некоторых команд будет отличаться.
1: Настройка сроков действия ключа
Настроить время действия существующего ключа можно с помощью команды expire, которая принимает в качестве аргументов имя ключа и количество секунд до истечения срока. Чтобы посмотреть, как это работает, выполните следующие две команды. Первая команда создает строковый ключ key_melon со значением “cantaloupe”, а вторая устанавливает срок его действия в 450 секунд:
set key_melon «cantaloupe»
expire key_melon 450
Если временной интервал был установлен успешно, команда expire возвратит (integer) 1. Если установить время не удалась, команда вернет (integer) 0.
Кроме того, вы можете завершить срок действия ключа в определенный момент времени – это делается с помощью команды expireat. Вместо количества секунд до истечения срока действия ключа в качестве аргумента она принимает временную метку Unix. Метка времени Unix – это количество секунд с начала эпохи Unix, или 00:00:00 UTC на 1 января 1970 года. В сети существует несколько инструментов, которые можно использовать для определения временной метки времени Unix, например, EpochConverter и UnixTimestamp.com.
К примеру, чтобы срок действия ключа key_melon истек в 8:30 вечера по Гринвичу 1 мая 2025 года (этот момент времени выражается временной меткой Unix 1746131400), можно использовать следующую команду:
expireat key_melon 1746131400
Обратите внимание, если временная метка, которую вы передали expireat, относится к прошедшему времени, команда немедленно удалит ключ.
2: Проверка срока действия ключа
Всегда, когда вы устанавливаете срок действия ключа, вы можете проверить, сколько осталось до истечения срока его действия (в секундах). Это можно сделать с помощью команды ttl, что расшифровывается как «time to live»:
ttl key_melon
(integer) 433
Для получения более детальной информации вы можете запустить команду pttl, которая покажет количество времени до истечения срока действия ключа в миллисекундах:
pttl key_melon
(integer) 431506
3: Сброс настроек непостоянных ключей
Если вы настроили ключ как непостоянный (то есть у него есть срок действия), любая команда, которая перезаписывает содержимое ключа, например set или getset, удалит эти настройки. Чтобы вручную сбросить время действия ключа, используйте команду persist:
Команда persist вернет вывод (integer) 1, если операция прошла успешно – это значит, что срок действия ключа сброшен и ключ стал постоянным.
Заключение
В этом мануале мы разобрались с управлением непостоянными ключами Redis и научились проверять срок действия ключей.
Шпаргалка по Redis
Про Redis (официальный сайт, материалы на Хабре) написано много, но мне до сего дня не хватало материала, который послужил бы шпаргалкой по его практическому использованию, а так же справочником по базовым теоретическим моментам. Постараюсь заполнить этот пробел в богатой базе знаний Хабра.
Я поставил перед собой цель показать возможности Redis с помощью примеров кода. После публикации приму любые предложения по улучшению материала.
Здесь используется общение с сервером через консольный клиент, но, основываясь на приведенных примерах, можно легко найти реализацию этих примеров в клиентских библиотеках на вашем любимом языке.
Ключи
Типы данных Redis
Базовые операции
Подробности о командах, связанных с этой задачей можно найти в документации в разделах Keys и Strings.
Задача 2, время жизни объекта.
Подробности о командах, связанных с этой задачей можно найти в документации в разделах Keys и Strings.
Задача 3, pipelining, выполнение нескольких команд одним запросом.
Pipelining удобно использовать для оптимизации массовых вставок.
Подробности о командах, связанных с этой задачей можно найти в документации в разделе Transactions.
Строки/числа
Задача 5, продемонстрировать основные строковые операции.
Задача 6, продемонстрировать операции над числами.
Подробности о командах, связанных с этими задачами можно найти в документации в разделе Strings.
Списки
Задача 7, создать список, продемонстрировать основные операции над списками.
Подробности о командах, связанных с этой задачей можно найти в документации в разделе Lists.
Множества, упорядоченные множества
Задача 8, создать множество, продемонстрировать основные операции над множествами.
Подробности о командах, связанных с этой задачей можно найти в документации в разделе Sets.
Задача 9, создать упорядоченное множество и продемонстрировано основные операции над ним.
В упорядоченном множестве элементы сравниваются по дополнительному параметру «score».
Подробности о командах, связанных с этой задачей можно найти в документации в разделе Sorted sets.
Хеш-таблицы
Задача 10, Создать хеш-таблицу и продемонстрировать основные операции над хешами.
Подробности о командах, связанных с этой задачей можно найти в документации в разделе Hashes.
Pub/Sub, сообщения в Redis
Задача 11, подписаться на сообщения на одном клиенте и отправить сообщение из другого.
Приведем окна двух клиентов, в первом окне совершается подписка на сообщения и видно отправленное из второго окна сообщение.
Задача 12, подписаться на сообщения на одном клиенте и отправить сообщение из другого. Подписку осуществить с помощью шаблонов.
Приведем окна двух клиентов, в первом окне совершается подписка на сообщения и видно отправленное из второго окна сообщение.
Подробности о командах, связанных с этими задачами можно найти в документации в разделе Pub/Sub.
Введение в ограничение числа запросов с Redis [часть 1]
За последнее время я написал несколько разных способов ограничения числа запросов с помощью Redis. Как в коммерческих, так и в личных проектах. В двух частях этой публикации я хочу охватить два разных, но связанных способа ограничивать число запросов — с использование стандартных команд Redis и с помощью Lua скриптов. Каждый последующий из описанных методов будет добавлять новые варианты использования и решать огрехи предыдущих.
Эта публикация предполагает, что у вас есть некоторый опыт работы с Python и Redis и, в меньшей степени — с Lua, но и тем, у кого такого опыта нет, тоже будет интересно.
Зачем ограничивать число запросов?
Например, Twitter ограничивает количество запросов к своему API, а Reddit и StackOverflow используют ограничения на количество сообщений и комментариев.
Кто-то ограничивает количество запросов, чтобы оптимизировать утилизацию ресурсов, кто-то борется со спамерами. Иными словами, в современном интернете, ограничение числа запросов к платформе ставит своей целью ограничить влияние, которое может оказать пользователь. Независимо от причины, давайте исходить из того, что мы должны подсчитывать некоторые действия пользователя и предотвращать их, если пользователь достиг или превысил какой-то предел. Давайте начнем с ограничения количества запросов к некоторому API, в максимум 240 запросов в час на одного пользователя.
Мы знаем, что нам нужно подсчитывать действия и ограничивать пользователя, так что нам потребуется немного вспомогательного кода. Во-первых, мы должны иметь функцию, которая дает нам один или несколько идентификаторов для пользователя, выполняющего действие. Иногда это просто IP пользователя, иногда его идентификатор. Я предпочитаю использовать оба, если это возможно. По крайней мере IP, если пользователь не авторизован. Ниже функция, получающая IP и идентификатор пользователя, используя Flask плагин Flask-Login.
Просто используйте счётчики
Теперь у нас есть функция, возвращающая идентификаторы пользователя и мы можем начать считать наши действия. Один из самых простых способов, доступных в Redis — вычислять ключ для диапазона времени и увеличивать в нём счётчик всякий раз, как происходит интересующее нас действие. Если число в счётчике превысило нужное нам значение, мы не позволим выполнить действие. Вот функция, которая использует автоматически потухающие ключи с диапазоном (и временем жизни) в 1 час:
Эта достаточно простая функция. Для каждого идентификатора мы увеличиваем соответствующий ключ в Redis и выставляем ему время жизни в 1 час. Если значение счетчика превысило лимит вы вернём True. В противном случае вернём False.
Вот и всё. Ну или почти. Это позволяет нам решить нашу задачу — ограничить количество запросов до 240 в час для каждого пользователя. Реальность однако такова, что пользователи быстро заметят, что лимит сбрасывается в начале каждого часа. И ничто им не помешает сделать свои 240 запросов в течении пары секунд сразу в начале часа. Наша работа пойдёт в таком случае на смарку.
Используем различные диапазоны
Наша первичная цель с ограничением запросов с почасовым базисом была успешной, но пользователи начинают слать все свои запросы к API как только это становится возможным (в начале каждого часа). Выглядит так, что помимо почасового ограничения нам стоит ввести посекундное и поминутное ограничение, чтобы сгладить ситуации с пиковым количеством запросов.
Предположим мы решили, что 10 запросов в секунду, 120 запросов в минуту и 240 запросов в час достаточно для наших пользователей, и позволит нам лучше распределять запросы с течением времени.
Чтобы это сделать, мы можем просто использовать нашу функцию over_limit ():
Это будет работать так как мы ожидали. Однако каждый из 3-х вызовов over_limit() может выполнить две команды Redis — одну для обновления счетчика и вторую для установки времени жизни для ключа. Мы выполним их для IP и идентификатора пользователя. В итоге может потребовать до 12 запросов в Redis чтобы просто сказать, что один человек превысил лимит по одной операции. Самый простой метод минимизировать число запросов к Redis — это использовать `pipelining` (конвейерные запросы). Такие запросы также называют в Redis транзакционными. В контексте Redis это означает, что вы пошлете много команд одним запросом.
Нам повезло, что наша функция over_limit() написана так, что можно легко заменить вызов INCR и EXPIRE на один запрос с MULTI. Это изменение позволит нам уменьшить число запросов к Redis с 12 до 6, когда мы используем её вместе с over_limit_multi().
Сокращение количества обращений к Redis вдвое это здорово, но мы всё ещё делаем 6 запросов просто чтобы понять, может ли пользователь сделать вызов к API. Можно написать другой вариант over_limit_multi(), который делает все операции сразу и проверяет ограничения после, но очевидно, что реализация будет иметь несколько ошибок. У нас получится ограничить пользователей и позволить им делать не более 240 запросов в час, правда, в худшем случае, это будет всего 10 запросов в час. Да, ошибку можно исправить, сделав ещё один запрос к Redis, а можно просто перенести всю логику в Redis!
Считаем правильно
Вместо того, чтобы исправлять нашу предыдущую реализацию давайте давайте перенесём её в LUA скрипт, который мы выполним внутри Redis. В этом скрипте мы будем делать тоже самое, что делали выше — пройдемся по списку ограничений, для каждого идентификатора увеличим счетчик, обновим время жизни и проверим не превысил ли счетчик лимит.
Посмотрите на кусок кода сразу после ‘local bucket’. Видите, что наш Lua скрипт выглядит как наше предыдущее решение и выполняет те же операции как и оригинальная over_limit()?
Заключение
Мы начинали с одного временного интервала, а в итоге, у нас есть метод ограничения числа запросов, который умеет работать с несколькими уровнями ограничений, работать с разными идентификаторами для одного пользователя и выполняет всего один запрос к Redis.
Собственно, любой из вариантов наших ограничителей может пригодится в разных приложениях.
Использование Redis EXPIRE для отслеживания онлайн-аудитории в Rails
Решение вопроса в сети пользователь или нет — это наверное как правило установка временной метки при обращении пользователя к приложению, а при необходимости узнать его (пользователя) текущий статус — сверка с этой временной меткой. Какой подход выбрать — решать Вам, но тот подход который предлагаю я — прост и не использует SQL базу данных, вместо этого используется Redis и одна из его встроенных возможностей — время жизни ключа ( expire ).
Собственно реализация
Выше простейший подход, но я рекомендую следующий
Gemfile
Не забудьте запустить bundle
Устанавливаем в online
Метод current_user скорее всего уже используется Вами — это тот метод, который возвращает текущего пользователя или nil — если пользователь не вошёл.
В сети?
Небольшой бонус — список онлайн пользователей
Небольшая переработка для anonymous
Для отслеживания анонимных посетителей (тех кто не зарегистрировался/не вошёл) подход аналогичный, с небольшим дополнением.
Ну и совсем чуть чуть по поводу размера базы данных
Redis хранит данные в оперативной памяти, поэтому перебор с размером базы данных может плохо сказаться на работе всего сервера. Для оценки использовалась пустая база данных (выполнил FLUSHALL перед этим) и вот этот небольшой скрипт на ruby. Для 9000 онлайн пользователей и 9000 онлайн анонимусов получилось так:
#UDP 1
Русские Блоги
Расширенные функции Redis и сценарии приложений
Расширенные функции Redis и сценарии приложений
Время жизни ключа в redis (истекает)
В redis вы можете использовать команду expire, чтобы установить время жизни ключа, и redis автоматически удалит его по истечении времени.
expire Установить время выживания (единица в секунду)
ttl просмотреть оставшийся срок службы ключа
настаивать отменить время жить
expireat [ключ] временная метка unix 1351858600
Redis транзакция (транзакция)
Сначала отправьте команды, принадлежащие транзакции, в redis для кеширования и, наконец, позвольте redis выполнить эти команды по очереди.
1: Синтаксическая ошибка: фатальная ошибка, все команды в транзакции не будут выполнены
2: Ошибка операции: не повлияет на выполнение других команд в транзакции
Redis не поддерживает откат
Именно потому, что redis не поддерживает функцию отката, redis может поддерживать краткие и быстрые транзакции.
Функция: контролировать один или несколько ключей и блокировать выполнение последующей транзакции при изменении значения отслеживаемого ключа.
Но нет гарантии, что другие клиенты не изменят это значение ключа, поэтому нам нужно повторно выполнить команды в транзакции после сбоя транзакции.
Примечание: после выполнения команды exec транзакции часы отменит мониторинг всех значений ключей.
unwatch: отменить мониторинг
Сортировка данных в Redis (сортировка)
Команда sort может сортировать типы списков, типы коллекций и типы упорядоченных коллекций.
Расширенные параметры получения
Расширить параметры магазина
Используйте параметр store, чтобы сохранить результат сортировки в указанном списке.
1: минимизировать количество элементов в ключе для сортировки
2. Используйте параметр limit, чтобы получить только те данные, которые вам нужны.
3: Если объем данных для сортировки велик, используйте параметр store как можно больше, чтобы кэшировать результат.
Модель «Опубликовать / подписаться»
Подписка по правилам: psubscribe
Отписаться по правилам: punsubscribe
Примечание: с помощью команды punsubscribe можно отказаться от подписки только на каналы, подписанные через psubscribe.
Значок операции: (После подписки на канал, каждый раз, когда канал публикует сообщение, оно может отображаться динамически)
очередь задач Redis
Очередь задач: используйте lpush и rpop (brpop), чтобы реализовать обычную очередь задач.
Это блокирующая версия команды RPOP.Если в данном списке нет элемента, который нужно раскрыть, соединение будет заблокировано командой BRPOP до тех пор, пока не будет обнаружено время ожидания или всплывающий элемент.
Когда задано несколько ключевых параметров, каждый список проверяется в порядке ключа параметра, и появляется хвостовой элемент первого непустого списка.
redis pipeline (конвейер)
Функция конвейера redis недоступна в командной строке, но redis поддерживает конвейеры, которые можно использовать в java-клиенте (jedis).
1. Без использования конвейерного метода вставка 1000 элементов данных занимает 328 миллисекунд.
2. Используя конвейерный метод, требуется 37 миллисекунд, чтобы вставить 1000 фрагментов данных.
При вставке большего количества данных преимущество конвейера становится более очевидным: при тестировании 100 000 блоков данных требуется 40 секунд, чтобы не использовать конвейер, и 378 миллисекунд для практического конвейера.
Настойчивость Redis (настойчивость)
Redis поддерживает постоянство двумя способами, которые можно использовать по отдельности или в комбинации.
Первый: режим RDB (режим сохранения по умолчанию redis)
Redis постоянный RDB
Время создания снимка Redis (в файле конфигурации redis.conf)
Redis автоматически реализует процесс создания снимков
1. Redis использует функцию fork для копирования копии текущего процесса (дочернего процесса).
2. Родительский процесс продолжает получать и обрабатывать команды, отправленные клиентом, в то время как дочерний процесс начинает записывать данные из памяти во временный файл на жестком диске.
3. После того, как дочерний процесс записал все данные, он заменит старый файл RDB временным файлом.На этом этапе операция создания моментального снимка завершена.
Примечание: Redis не будет изменять файл RDB во время процесса создания моментального снимка. Старый файл будет заменен новым только после того, как моментальный снимок будет завершен, что означает, что файл RDB будет готов в любой момент.
Это позволяет нам создавать резервную копию базы данных Redis, регулярно создавая резервные копии файлов RDB.
Вручную выполните команду save или bgsave, чтобы позволить redis выполнить снимок.
Преимущества и недостатки rdb
Преимущества: поскольку здесь хранятся файлы моментальных снимков данных, их очень удобно восстанавливать.
Недостаток: все данные, измененные с момента последнего снимка, будут потеряны.
Сохранение Redis AOF
Постоянство метода aof осуществляется через файлы журнала. Redis не включает AOF по умолчанию, и его можно включить с помощью параметра appendonly.
Сроки синхронизации команды записи redis
перезапись файла журнала
Вручную выполнить bgrewriteaof для перезаписи
Процесс перезаписи относится только к данным в памяти и не имеет ничего общего с предыдущим файлом AOF.
Так называемая «перезапись» на самом деле неоднозначный термин. Фактически, перезапись AOF не требует какой-либо записи или чтения исходного файла AOF. Она нацелена на текущее значение ключа в базе данных.
Динамическое переключение режима сохраняемости Redis с RDB на AOF (поддержка Redis 2.2 и выше)
1. При запуске redis, если включены и rdb persistence, и aof persistence, программа будет предпочтительно использовать метод aof для восстановления набора данных, поскольку данные, сохраненные в методе aof, обычно являются наиболее полными. Если файл aof отсутствует, после запуска содержимое базы данных будет пустым.
2. Если вы хотите переключить работающую базу данных Redis с RDB на AOF, рекомендуется сначала использовать динамическое переключение, затем изменить файл конфигурации и перезапустить базу данных. (Вы не можете самостоятельно изменить файл конфигурации и перезапустить базу данных, иначе данные в базе данных будут пустыми.)
команда config в Redis
Информация о параметрах может быть установлена динамически с помощью набора конфигураций, и она станет недействительной после перезапуска сервера.
Используйте config get для просмотра всех параметров, которые могут быть установлены с помощью команды config set
Используйте команду config rewrite, чтобы перезаписать файл redis.conf, указанный при запуске сервера Redis (можно использовать только Redis 2.8 и выше), главным образом для сохранения команд, динамически указанных с помощью config, установленного в файл конфигурации.
Примечание. Файл redis.conf перезаписывается командой config rewrite атомарно и последовательно: если возникает ошибка перезаписи или происходит сбой сервера во время перезаписи, перезапись не удастся и исходный файл redis.conf не будет изменен. Если перезапись прошла успешно, файл redis.conf будет новым файлом после перезаписи.
Стратегия безопасности Redis
Установить пароль базы данных
параметр привязки (разрешает доступ к базе данных только по указанному IP)
Измените имя команды
инструменты Redis
Командная строка redis-cli
Redisclient (инструмент визуализации базы данных Redis, не очень практичный)
команда redis info
Он возвращает различную информацию и статистику о сервере Redis в формате, который легко анализировать и легко читать.
Указав необязательный раздел параметров, вы можете заставить команду возвращать только определенную часть информации:
Слишком много контента, подробная ссылка
Использование памяти Redis
Если вы используете 64-битную операционную систему, условно говоря, она займет немного больше памяти. Это связано с тем, что указатель занимает 8 байт в 64-битной системе, но 64-битная система также может поддерживать больший объем памяти, поэтому он работает очень быстро. Сервису redis по-прежнему рекомендуется использовать 64-битный сервер.
Максимальное количество ключей, хранящихся в экземпляре Redis
Теоретически Redis может обрабатывать до 2-х до 32-й степени ключей и был протестирован на практике.Каждый экземпляр хранит не менее 250 миллионов ключей.
Оптимизация Redis 1
Упростите названия ключей и значения ключей
Названия клавиш: постарайтесь быть как можно более краткими, но вы не можете использовать названия клавиш, которые нелегко понять, только для экономии места.
Пары «ключ-значение». Если количество пар «ключ-значение» фиксировано, оно может быть представлено числами, такими как 0 и 1 (например: мужской / женский, правильный / неправильный).
Если бизнес-сценарий не требует сохранения данных, отключите все методы сохранения для достижения максимальной производительности.
Оптимизация внутреннего кодирования (разбираетесь сами)
Redis предоставляет два внутренних метода кодирования для каждого типа данных, а redis автоматически настраивает соответствующий метод кодирования при различных обстоятельствах. (как показано на картинке)
Когда вы обнаружите, что производительность Redis снижается, вы можете проверить, какие команды вызывают это.
Оптимизация Redis 2
Измените стратегию распределения памяти ядра Linux
Следующие проблемы могут возникнуть во время операции Redis
Когда redis выполняет резервное копирование данных, он создает дочерний процесс. Теоретически память, занятая дочерним процессом, такая же, как и у родительского процесса. Например, память, занятая родительским процессом, составляет 8 ГБ. В настоящее время должно быть 8 ГБ памяти. также может быть выделен дочернему элементу. Недоступно, это часто приводит к отключению сервера Redis или слишком высокой нагрузке ввода-вывода, что снижает эффективность. Таким образом, стратегия распределения памяти должна быть установлена на 1 (что указывает на то, что ядро позволяет выделять всю физическую память независимо от текущего состояния памяти).
Есть три стратегии распределения памяти
Необязательные значения: 0, 1, 2.
0 означает, что ядро проверит, достаточно ли доступной памяти для процесса приложения; если достаточно доступной памяти, приложение памяти разрешено; в противном случае приложение памяти не работает, и процессу приложения возвращается ошибка.
1. Независимо от того, сколько памяти требуется, приложения разрешены.
2. Разрешается выделять только размер физической памяти и памяти подкачки. (Память подкачки обычно составляет половину физической памяти)
Добавить в /etc/sysctl.conf
Оптимизация Redis 3
Закройте прозрачные огромные страницы (THP)
THP приведет к блокировке памяти, чтобы повлиять на производительность Redis, рекомендуется закрыть
Используйте пользователя root для выполнения следующих команд
Добавьте эту команду в этот файл /etc/rc.local
Оптимизация Redis 4
Измените максимальное количество прослушивателей TCP в Linux
В среде с высоким уровнем параллелизма вам необходимо большое значение невыполненной работы, чтобы избежать проблем с медленным подключением клиентов. Обратите внимание, что ядро Linux незаметно уменьшает это значение до значения / proc / sys / net / core / somaxconn, поэтому вам нужно обязательно увеличить два значения somaxconn и tcp_max_syn_backlog для достижения желаемого эффекта.
Оптимизация Redis 5
Ограничьте размер памяти Redis
Просмотр использования памяти с помощью команды redis info
Если maxmemory не установлен или равен 0, 64-разрядная система не ограничивает память, а 32-разрядная система использует до 3 ГБ памяти.
Измените maxmemory и maxmemory-policy в файле конфигурации
Если можно определить, что общий объем данных невелик и памяти достаточно, нет необходимости ограничивать размер памяти, используемый redis. Если объем данных непредсказуем, а память ограничена, попробуйте ограничить размер памяти, используемый redis, чтобы избежать redis с использованием разделов подкачки или ошибок OOM.
Примечание. Если объем памяти не ограничен, раздел подкачки будет использоваться, когда физическая память израсходована, поэтому производительность низкая. Если объем памяти ограничен, данные не могут быть добавлены после достижения указанной памяти, в противном случае произойдет ошибка OOM. будет сообщено. Вы можете установить maxmemory-policy для удаления данных, когда памяти недостаточно.
Если использование памяти экземпляром Redis превышает доступный максимальный объем памяти (used_memory> доступный максимальный объем памяти), операционная система начинает обмениваться памятью и местом подкачки, а также записывать старый или больше не используемый контент из памяти на жесткий диск ( Это пространство называется разделом подкачки), чтобы освободить новую физическую память для использования новых страниц или активных страниц (страниц).
План устранения неполадок:
Если моментальный снимок RDB или стратегия сохранения AOF не включена во время использования Redis, кэшированные данные могут быть потеряны при сбое Redis. Поскольку, когда использование памяти Redis превышает 95% доступной памяти, часть данных начинает обмениваться между памятью и пространством подкачки, и в это время может возникнуть риск потери данных.
Когда функция моментального снимка включается и запускается, Redis будет форкнуть дочерний процесс, чтобы сделать полную копию данных в текущей памяти и записать ее на жесткий диск. Следовательно, если функция моментального снимка запускается, когда текущая используемая память превышает 45% доступной памяти, подкачка памяти, выполняемая в это время, станет очень опасной (данные могут быть потеряны). Если в это время на экземпляре выполняется много частых операций обновления, проблема станет более серьезной.
Избегайте этой проблемы, уменьшив использование памяти Redis, или используйте следующие методы, чтобы избежать подкачки памяти:
3. Восстановить ключ. В файле конфигурации Redis (обычно называемом Redis.conf) вы можете ограничить максимальный объем памяти, используемый Redis, установив значение атрибута «maxmemory». После изменения перезапустите экземпляр, чтобы он вступил в силу. Вы также можете использовать клиентскую команду config set maxmemory для изменения значения. Эта команда вступает в силу немедленно, но станет недействительной после перезапуска. Для обновления файла конфигурации необходимо использовать команду config rewrite. Если функция моментального снимка Redis включена, значение «maxmemory» должно быть установлено на 45% доступной памяти системы, потому что моментальный снимок требует удвоения памяти для копирования всего набора данных, что означает, что если в настоящее время используется 45%, он будет 95% (45% + 45% + 5%), из которых 5% зарезервировано для других расходов. Если функция моментального снимка не включена, maxmemory можно установить до 95% доступной памяти системы.
Когда использование памяти достигает установленного максимального порога, вам необходимо выбрать стратегию повторного использования ключей.Можно изменить значение атрибута maxmemory-policy в файле конфигурации Redis.conf. Если все ключи в наборе данных Redis имеют время истечения срока действия, то лучше выбрать стратегию «volatile-ttl». Но если срок действия ключа не истекает быстро при достижении максимального предела памяти, или если срок действия не установлен вообще. Тогда более уместно установить значение «allkeys-lru», которое позволяет Redis выбрать для удаления ключ, который использовался недавно, из всего набора данных (алгоритм исключения LRU). Redis также предоставляет некоторые другие стратегии устранения, а именно:
Установив для maxmemory значение 45% или 95% доступной системной памяти (в зависимости от стратегии сохранения) и установив для параметра «maxmemory-policy» значение «volatile-ttl» или «allkeys-lru» (в зависимости от настройки срока действия), можно быть более точным Ограничьте максимальное использование памяти Redis.В большинстве сценариев использование этих двух методов может гарантировать, что Redis не будет обмениваться памятью. Если вас беспокоит потеря данных из-за ограниченного использования памяти, вы можете установить значение noneviction, чтобы запретить удаление данных.
Оптимизация Redis 6
Сценарии приложения Redis
Опубликовать и подписаться
Распространенной задачей системы является поддержание отображения данных пользователем во время обновления. Функция pub / sub в Redis использует команды SUBSCRIBE, UNSUBSCRIBE и PUBLISH, чтобы упростить эту задачу.
Ограничьте частоту посещения веб-сайта
Использование различных статистических данных очень обширно, например, желание знать, когда блокировать IP-адрес. Команда INCRBY упрощает это, ведя счет с помощью атомарного приращения; GETSET используется для сброса счетчика; истекший атрибут expires используется для подтверждения того, когда следует удалить ключевое слово.