Redis как очистить кэш
Обновлено: 04.07.2024
Я использую redis в качестве драйвера сеанса, и я хочу очистить кеш, сохраняя данные сеанса, чтобы в основном пользователь мог оставаться в системе. Любые предложения относительно реструктуризации или обработки текущей ситуации?
Примечание . Я не хочу использовать отдельный экземпляр Redis для сеансов и других данных кеша.
4 ответа
Вступление
По умолчанию redis предоставляет вам 16 отдельных баз данных, но laravel из коробки будет пытаться использовать базу данных 0 как для сеансов, так и для кеширования.
Наше решение состоит в том, чтобы позволить Redis кэшировать с использованием базы данных 0 и базы данных 1 для сеанса, чтобы очистить сеанс с помощью задачи php artisan cache:clear .
1. Настройка подключения к Session Redis
Измените config/database.php , добавьте ключ session к параметру redis :
2. Используйте соединение session
Измените config/session.php , измените следующее:
3. Использование Redis в качестве драйвера сеанса
Измените .env , измените SESSION_DRIVER :
4. Тестирование
Выполните следующую команду artisan, затем проверьте состояние входа в систему:
Если состояние входа сохраняется, вуаля!
Laravel Cache :: clear () отправляет команду Redis flushall, которая сбрасывает все, что, по моему опыту, не очень полезно. Вам нужно будет расширить класс кеша и создать настраиваемый набор для индексации данных кеша, которые вы хотите очистить. Затем создайте другую функцию для чтения набора и выполните команду Redis del () для каждого ключа в наборе. Разместите рабочий код и при необходимости подробно расскажу
Предложение Notagolfers о разделении кеша и сеанса в разные базы данных Redis не является обязательным, но вам все равно нужно будет расширить класс кеша для реализации переключателя конфигурации базы данных Redis.
В параметрах подключения Redis есть «база данных», просто выберите разные базы данных для сеанса и кеширования. Я просто надеюсь, что драйвер кеша redis использует flushdb, а не flushall для очистки :).
Я не знаю Laravel, но в целом два лучших варианта:
Измените формат ключей кеша. Вы должны использовать ключи кэша с версией, чтобы вы могли делать это в будущем, например, "cache.1". так что вы можете увеличить, и тогда все ваши ключи сразу станут неактуальными.
Переместите кеш на другой номер базы данных в том же экземпляре Redis. Таким образом, вы также можете позже выполнить FLUSHDB с этим номером базы данных, чтобы очистить кеш.
В качестве примечания: обычно хранить кеш и другие вещи в одном экземпляре Redis - плохая идея, так как в кешах вы обычно используете выселение на основе LRU, и вы не хотите смешивать это с менее изменчивыми ключами.
В первой и второй частях мы рассмотрели настройку способа при котором Nginx напрямую сможет читать страницы из Redis, что позволит снизить нагрузку на сервер и фантастически увеличит скорость работы сайта. В этой статье речь пойдёт об очистке Redis Page Cache. На самом деле, метод, которым мы будем пользоваться для очистка нашего кеша страниц в Redis, практически не отличается от стандартных методов очистки внешних кешей, навроде кеша Varnish или CDN.
Итак, у нас настроен NGINX, установлен и работает наш экспериментальный модуль Redis Page Cache, который сохраняет plain-версии страниц сайта в Redis.
Для очистки кеша нам понадобятся следующие модули Drupal:
Включаем все модули, не забываем про Purge UI.
Суть метода
Но у записей из Redis Page Cache нет никакой информации о времени истечения кеша, нет тегов. Каким образом можно отслеживать изменения и отправлять запросы на очистку нужных страниц?
Ответ — модуль URLs queuer. Этот модуль создаёт таблицу с соответствиями URL и кеш-тегов Drupal. На основе этих соответствий, модуль формирует очередь на очистку. Другими словами, это посредник связующий кеш-теги Drupal и адреса страниц.
The module trains its traffic registry by collecting URLs from requests that miss cache inside Drupal's own page cache. These URLs are stored along with their associated cache tags inside this same traffic registry. Now when Drupal invalidates a set of tags because someone edited a page, these tags are used to fetch URLs from the registry and are added to the Purge queue.
Как раз то, что нам необходимо.
Заходим в настройки Purge: /admin/config/development/performance/purge
И задаём настройки:
1. Name: название пурджера может быть любым.
2. Type: Url
3. Hostname: домен вашего проекта
4. Port: порт
5. Path: /rpcache/rpcache-clear
6. Request Method: POST
7. Scheme: протокол
Далее понадобится вторая вкладка Headers:
В ней нужно указать заголовки и их значения, как на картинке.
Как можно догадаться, в нашем модуле Redis Page Cache есть endpoint по адресу /rpcache/rpcache-clear, который принимает эти запросы и очищает нужные страницы из Redis.
Настройка URLs queuer
Очень важна правильная настройка этого модуля, если в других модулях «или работает или не работает», то некорректная настройка этого модуля приведёт к проблемам в работе внешнего кеша в Redis, а точнее, к проблемам с очисткой кеша.
Крайне желательно внимательно прочитать всё описание модуля URLs queuer.
На странице /admin/config/development/performance/purge, во вкладке QUEUE есть настройки:
Важно, чтобы эти настройки соответствовали настройкам Redis Page Cache /admin/config/development/rpcache
В частности, проверяем и редактируем список URL, которые не должны обрабатываться модулем URLs queuer. Эти страницы не будут попадать в систему учёта (traffic registry) для отслеживания кеширования.
Эти же самые страницы должны быть отмечены, как исключённые в настройках кеша /admin/config/development/rpcache, иначе не будет работать механизм их очистки.
Очистка кеша
По мере обновления кеша Drupal, в очереди на очистку появляются элементы /admin/config/development/performance/purge:
Очистить внешний кеш можно командой drush p-queue-work, она отображается в этой же колонке вверху. Запустится пурджер, то есть обработчик, который мы настроили выше, и отправит команды на очистку внешнего кеша.
Как это работает: например, мы отредактировали какую-то страницу, Drupal автоматически сбросил свой кеш для этой страницы, модуль URLs queuer сопоставил теги и адрес страницы, добавил её в очередь на очистку внешнего кеша.
Чуть более года назад мне посчастливилось погрузиться в углублённое изучение Redis. Всё, что я знал про него на тот момент, это две команды — get и set. Примерно в это же время у нас начался плавный переход со Standalone Redis на Redis Cluster.
Почитать про переход на кластер можно тут, а сегодня я хочу рассказать о том, что я узнал, о проблемах, которые могут возникнуть, как их отлавливать и что со всем этим делать.
Большую часть времени ваша грядка будет работать и ничего плохого не произойдёт, но если не начать за ней ухаживать, то могут возникнуть серьёзные проблемы:
Невозможность подключиться из-за скопившихся клиентов.
Неоправданно большое количество соединений по причине некорректной настройки таймаутов или непредвиденной конфигурации клиентов.
Потеря данных до истечения их реального срока жизни в связи с вытеснением.
Ненормированное распределение соединений, команд или сетевой нагрузки между нодами кластера.
Слишком большой коэффициент кеш-промахов.
Проблемы, возможности и искусственные ограничения
Контроль за использованием команд
Неосторожные действия клиентов могут серьёзно навредить работе приложения. Мы можем попытаться уменьшить вероятность вреда, и в этом нам поможет встроенный механизм ACL, который разделяет пользователей и их возможности.
ACL поставляется с 6 версией Redis. Если у вас нет возможности обновить приложение, то создатели рекомендуют использовать rename-command
Если у вас есть необходимость и возможность создавать инструменты для разработчиков, то следует закладывать ограничения на уровне библиотеки, не реализуя опасные команды: flushdb, flushall, keys и т.д.
ACL (Access Command List) поддерживает не только выборочную блокировку команд, но и заготовленные группы. Если вы уверены что нет никого, кто бы использовал нежелательные команды, то стоит прибегнуть к разделению прав на уровне пользователей.
Рассмотрим пример, в нём показано, как может выглядеть файл с заготовленным пользователем cache. У него не будет доступа к ключам, которые не сопоставляются с образцом cache:*, а также отсутствует возможность пользоваться командами, которые могут помешать другим пользователям:
Как минимум, стоит отобрать выполнение admin-команд у обычных пользователей. Если у вас много различных групп пользователей, которые обращаются к общей базе, и вы не можете разделить данные между разными экземплярами, то стоит задуматься о выдаче личных пользователей под каждую группу.
Главная боль — сканирование и поиск по паттерну
Во время переезда на Redis Cluster одной из основных проблем стал отказ от поиска по шаблону (KEYS) и не заканчивающегося сканирования (SCAN).
Поиск по паттерну выполняется при помощи команды KEYS, которая является блокирующей операцией и выполняется за О(n), где n — количество ключей в базе. Использовать эту команду в production-окружении крайне не рекомендуется, но если воспользовались, то следует отказаться в пользу сканирования.
Сканирование (команда SCAN) также выполняется за O(n), где n — переданное клиентом количество строк для чтения за одну итерацию. SCAN не панацея и может оказаться бесполезной альтернативой, ведь если вы не ограничиваете строго выборку максимального значения за одну итерацию, то ничто не мешает появлению внезапных длительных блокирующих запросов (если верить документации, то сканирование 1 миллиона ключей на локальном ноутбуке может занимать 40 мс).
При работе с кластером нужно строже всего соблюдать запрет на использование команд KEYS и SCAN, так как все данные будут находиться в одной базе и придётся перебирать все ключи.
Решить проблему блокирующего поиска по шаблону можно несколькими способами:
Если у вас standalone-конфигурация, то поможет разбивка ключей по разным базам. Также можно развернуть отдельную версию Redis, и тогда при использовании SCAN ключи будут перебираться только внутри конкретной базы и только среди необходимого набора ключей.
В случае с кластерами:
Если вы не ограничены в ресурсах и избавиться от частого сканирования невозможно, то следует развернуть отдельный кластер под подобные операции.
Если вы ограничены в ресурсах, то следует пересмотреть способ хранения данных и исследовать все возможности Redis. Быть может, необходимости в поиске по шаблону нет и вы сможете обойтись наименее затратными по сложности командами.
На практике мы используем несколько вариантов в зависимости от ситуации. Пересмотр способа хранения может показаться надуманным решением, но однажды подобный анализ помог выявить мёртвую функциональность, которая больше всего нагружала базу.
Конфигурация
Упомянутые параметры статистики можно посмотреть, выполнив команду INFO.
maxclients
timeout
По умолчанию timeout установлен в 0, это означает, что сервер не будет закрывать соединения даже после долгого простоя. Такая ситуация может возникнуть из-за неправильной конфигурации клиента, который не закрывает соединения. Привести это может к большому количеству открытых соединений и невозможности подключиться к серверу (при достижении maxclients).
Как может выглядеть список клиентов при плохо настроенном клиенте:
Установка этого параметра не избавит вас от некорректно настроенного клиента, но может помочь увеличить время жизни приложения за счёт принудительного обрыва простаивающего соединения.
Текущее количество клиентов можно посмотреть в статистике через параметр connected_clients. Следует настроить уведомление, когда значение приближается к максимально допустимому. Также стоит обратить особое внимание на idle-соединения, их наличие поможет выявить клиенты с дефектами. Отдельного параметра, показывающего количество таких клиентов, нет, но посчитать их можно, выполнив команду:
tcp-keepalive
По умолчанию имеет значение 300, полезен для обнаружения мёртвых клиентов.
Если timeout и tcp-keepalive установлены в 0, то соединения могут находиться в состоянии idle до перезапуска сервера.
maxmemory
Задаёт максимально возможное количество потребляемой памяти. Указывать можно как абсолютные значения, так и проценты. Рекомендуется установить ограничение, если на сервере с Redis есть и другие приложения. Тогда Redis не сможет захватить всё свободное пространство. При достижении указанного значения система попытается высвободить память, руководствуясь алгоритмом, указанным в maxmemory-policy:
volatile-lru — вытесняются значения, которые дольше всего не запрашивались, у которых задан срок действия;
allkeys-lru — вытесняются значения, которые дольше всего не запрашивались;
volatile-lfu — вытесняются значения, которые наименее часто используется, у которых задан срок действия;
allkeys-lfu — вытесняются значения, которые наименее часто используется;
volatile-random — вытеснение случайных ключей у которых задан срок действия;
allkeys-random — вытеснение случайных ключей;
volatile-ttl — вытеснение ключей, у которых истекает срок действия;
noeviction — отключает вытеснение, будет просто возвращаться ошибка.
Следить за количеством вытесненных ключей можно в статистике через параметр evicted_keys. Чтобы заметить момент, когда память начинает заканчиваться, стоит настроить уведомления на perc_memory. Этот параметр можно посчитать по формуле:
Далее используйте perc_memory в качестве порогового значения, рекомендуется сигнализировать о проблеме, если значение приближается к 85.
requirepass
unixsocket
Если ваше приложение находится на одном сервере с Redis, попробуйте использовать unix-сокеты, это поможет уменьшить задержу.
Эффективность использования
В этом разделе мы не будем рассматривать системные метрики вроде CPU и RAM, а сосредоточимся на внутренней статистике приложения.
Здесь представлены не все параметры, часть советов по отслеживанию эффективности уже дана в разделе «Конфигурация».
Представленные ниже параметры полезно выводить на графиках чтобы следить за их изменениями.
Ключи
Стоит отслеживать количество ключей, чтобы видеть всю картину происходящего. Эта метрика поможет заметить аномалии и внезапную просадку, чтобы затем по дополнительным метрикам разобраться в причинах происходящего (будь то вытеснение или штатная ситуация).
Кэш-промахи
Эта метрика покажет, сколько раз запрашивали данные, которых уже нет в хранилище. Вычисляется по формуле:
Если значение hit_rate маленькое, то данные слишком рано исчезают, а приложение ожидает их увидеть. Такое может быть из-за истечения срока действия или политики вытеснения ключей в связи с нехваткой памяти (maxmemory-policy). Если Redis у вас используется как кеш перед основным хранилищем, то побочным эффектом станет увеличение задержки в работе приложения из-за необходимости часто обращаться к основной базе данных.
Клиенты
Эта метрика показывает количество клиентов в единицу времени. В случае с кластером и проблемой неравномерного распределения будет заметно, что на какой-то из нод клиентов в разы больше.
Клиенты, выполняющие блокирующие операции
Операции над списками (BLPOP, BRPOP, BRPOPLPUSH, BLMOVE, BZPOPMIN, BZPOPMAX) могут приводить к длительным блокировкам. Увидеть количество таких клиентов можно через параметр blocked_clients. Эти команды будут блокировать до тех пор, пока список, с которым они работают, не перестанет быть пустым или пока не отвалятся по таймауту. Настройте мониторинг увеличения этого параметра, если он растёт, то это звоночек, что ваше приложение внезапно может стать медленным.
Большой разрыв между количеством клиентов на нодах кластера
Количество подключений на нодах может отличаться на два порядка и более. Причины разные: клиент, который не закрывает соединение и при первом подключении обращается к «первой» ноде за картой слотов, или неравномерное распределение ключей. Следить за этим поможет комплексный набор метрик ключей и соединений по всем нодам или профилирование кластера и составление отчёта.
Пропускная способность
Текущее количество команд — хорошая метрика, позволяющая в реальном времени наблюдать за активностью и доступностью Redis. Количество команд, обработанных за секунду, показывает параметр instantaneous_ops_per_sec. Отслеживая его, можно увидеть аномальное поведение, такое как плавные и резкие падения до нуля, что может сигнализировать о блокирующих клиентах.
Обработка грядки инсектицидами
Для упрощения профилирования конфигурационных файлов была написана утилита insecticide, она поможет упростить и ускорить анализ конфигурационных файлов, найдёт возможные проблемы или даст советы по настройке вашего Redis'а.
Пример использования
Результатом работы будет отчёт с рекомендацией, причиной и критичностью. Для получения отчёта достаточно передать путь до конфигурационного файла redis.conf:
Планы
В ближайших планах — сделать инструмент, который позволит подробно анализировать Redis (в том числе кластер), чтобы выяснить:
равномерность распределения ключей;
разницу между количеством клиентов между нодами;
разницу в размере данных между нодами кластера;
Подводя итог
Хочется отметить, что всё индивидуально и эффективность использования зависит от того, какие данные вы храните и насколько они вам нужны. Добиться максимального результата для кеш-сервера, шины данных или постоянного хранилища — это абсолютно разные задачи, и приведённые в статье советы подходят не для каждого случая. Из общих рекомендаций я бы выделил:
Следите за количеством подключённых клиентов и за библиотеками, которыми пользуются разработчики, проводите аудит сервисов.
Настройте мониторинг состояния системы в реальном времени: количество команд, кеш-промахов, ключей, нагрузка на сеть, CPU, RAM.
По возможности ограничивайте использование команд из групп admin, dangerous, slow и blocking.
Обратите внимание, что Redis версии 4.0.0 и выше теперь может удалять ключи в фоновом режиме в другом потоке без блокировки сервера. Параметр ASYNC был добавлен к FLUSHALL и FLUSHDB, чтобы разрешить асинхронное освобождение всего набора данных или отдельной базы данных.
Предупреждение: однажды удаленные данные / ключи / значения не могут быть восстановлены. Будьте осторожны при вводе следующих команд.
Синтаксис для очистки кеша Redis
Синтаксис для очистки кеша Redis из приглашения оболочки следующий: Имя хоста сервера по умолчанию установлено на 127.0.0.1, а порт на 6379. Мы можем переопределить его следующим образом: Вы можете указать пароль для использования при подключении к серверу, передав вариант для redis-cli:
redis-cli FLUSHDB
redis-cli -n DB_NUMBER FLUSHDB
redis-cli -n DB_NUMBER FLUSHDB ASYNC
redis-cli FLUSHALL
redis-cli FLUSHALL ASYNC
$ redis-cli -h -p command
$ redis-cli -h 192.168.5.100 -p 6000 FLUSHDB
$ redis-cli -h 10.8.0.1 FLUSHALL
-a
$ redis-cli -a '' COMMAND
$ redis-cli -a 'SuperSecretPassword' -h 10.8.0.5 -p 6379 -n 2 FLUSHDB
Примеры - удаление всех ключей с помощью redis-cli
Введите следующую команду, чтобы удалить все ключи БД №4:
$ redis-cli -n 4 FLUSHDB
Примеры выходных данных:
Чтобы удалить все ключи всей существующей базы данных, запустите:
$ redis-cli FLUSHALL
Примеры выходных данных:
Автоматизация удаления кеша Redis с помощью инструмента Ansible DevOps
Допустим, у вас работает 10 разных серверов Redis, и вы хотите удалить все ключи всех существующих БД. Создайте файл хоста следующим образом:
$ cat hosts
Примеры выходных данных:
Теперь все, что вам нужно сделать, это выполнить следующую команду (при условии, что ключи SSH установлены между вашей рабочей станцией и всеми другими виртуальными машинами / серверами без операционной системы).
$ ansible -i hosts redis -m command -a '/usr/bin/redis-cli FLUSHALL'
Примеры выходных данных:
Замечание о кластере Redis
Вы используете кластер? Вам нужно запустить команду FLUSHDB или FLUSHALL на каждом главном узле. Например, запустите следующую команду на трех главных узлах, используя цикл bash for
Очистка кеша / узла Redis с консоли при использовании кластера AWS Elasticache
Читайте также: