Каталог статей

1. Сценарии использования Redis

2. Проникновение в кэш

3. Поломка кэша

4. Лавина кэша

5. Следует ли сначала удалить кэш или сначала изменить базу данных?

• 5.1 Проблемы существуют
• 5.2 Двойное написание непротиворечиво
  • 5.2.1 Распределенная блокировка
  • 5.2.2 Асинхронное уведомление
• 5.3 Резюме

6. Персистентность Redis — Redis как кеш, как сохранить данные

• 6.1 RDB
  • 6.1.1 Введение в РБД
  • 6.1 2 Принцип работы РБД
• 6.2 AOF
• 6.3 Сравнение RDB и AOF
• 6.4 Резюме

7. Стратегия истечения срока действия данных Redis

• 7.1 Ленивое удаление
• 7.2 Обычное удаление
• 7.3 Резюме

8. Стратегия удаления данных Redis

• 8.1 Восемь стратегий удаления данных
• 8.2 Стратегия устаревания данных – рекомендации по использованию
• 8.3 Другие вопросы интервью о стратегиях удаления данных
• 8.4 Резюме

1. Сценарии использования Redis

Если произойдет проникновение, поломка или лавина кэша, как это решить?

2. Проникновение в кэш

проникновение в кэш：Запросне существуетданные,Mysql не может запрашивать данные и не записывает их напрямую.,Это приведет к тому, что каждый запрос будет проверять данные базы данных.

Решение 1. Кэшируйте пустые данные. Данные, возвращаемые запросом, пусты, и пустой результат по-прежнему кэшируется. {ключ: 1, значение: ноль}

• преимущество：Простой
• недостаток: потреблять память,Могут возникнуть несоответствия

Решение второе: фильтр Блума

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

фильтр Блума

растровое изображение：Эквивалент**（bit）КусочекМассив единиц. Каждая единица в массиве может хранить только двоичные числа.0или1**

фильтр Блумаэффект：фильтр Блума можно использовать для определения того, находится ли элемент в коллекции.

Подвести итог

1.Сценарии использования Redis

• Ответ в зависимости от бизнеса, указанного в вашем резюме.
• кэш—— проникнуть、авария、лавина、Двойное письмо последовательное、Выносливость、Срок действия данных истекает、стратегия устранения
• Распределенная блокировка——setnx、redisson

2. Что такое проникновение кэша и как его решить

• проникновение в кэш：Запросне существуетданные,Mysql не может запрашивать данные и не записывает их напрямую.,Это приведет к тому, что каждый запрос будет проверять данные базы данных.,Может привести к зависанию БД,В этом случае велика вероятность того, что на вас напали.
• Решение первое：кэшпустые данные
• Решение второе: фильтр Блума

3.Внедрение фильтра Блума.

• фильтр Блума в основном используется для определения того, находится ли элемент в коллекции. Мы использовали фильтр, реализованный redisson. Блума。
• Его нижний уровень в основном инициализирует относительно большой массив, в котором хранятся двоичные значения 0 или 1. Все они вначале равны 0. Когда приходит ключ, после трех вычислений хэша нижний индекс данных находится по модулю длины массива, а затем исходный 0 в массиве заменяется на 1. Таким образом, позиции из трех массивов можно отметить наличие ключа. Процесс поиска тот же.
• Конечно, есть недостаток,Капельные фильтры могут привести к определенным ошибочным суждениям.,Обычно мы можем установить этот уровень ошибочных оценок.,Вероятно, не более 5%,На самом деле, эта ошибка неизбежна.,В противном случае вам придется увеличить длину массива.,На самом деле он довольно разделен,Принимаются даже проекты со средним уровнем ошибочных оценок в пределах 5%.,Это не перегружает базу данных при высоком уровне параллелизма.

3. Поломка кэша

Разбивка кэша：кому-тоkeyУстановлен срок годности,Когда срок действия ключа истекает,В это время произошло большое количество одновременных запросов на этот ключ.,Эти одновременные запросы могут мгновенно перегрузить БД.

• Решение первое：блокировка мьютекса
• Решение 2：Логическое истечение срока действия

Подвести итог：

• Разбивка кэша：кому-тоkeyУстановлен срок годности,Когда срок действия ключа истекает,В это время произошло большое количество одновременных запросов на этот ключ.,Эти одновременные запросы могут мгновенно перегрузить БД.
• Решение первое：блокировка мьютекса,Сильная консистенция,Плохая производительность。когдакэш Когда недействительно,Не загружайте сразу db, сначала используйте setnx, например Redis, чтобы установить мьютекс, а затем загрузите его, когда операция завершится успешно. db и вернитесь к установке кэша, в противном случае попробуйте метод getкэш еще раз.
• Решение 2: Логическое истечение срока действия,Высокая доступность,Отличная производительность,Нет никакой гарантии, что данные будут абсолютно согласованными.。设置когда前keyЛогическое истечение срока действия,Идея, вероятно, заключается в следующем:

① При настройке ключа установите поле срока действия и сохраните его в кеше. Не устанавливайте срок действия для текущего ключа.

②При запросе определите, истекло ли время после получения данных из Redis.

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

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

4. Лавина кэша

лавина кэшаотносится к большому количествукэшkeyНедействителен одновременноили ВОЗRedisСервис отключен,В результате в базу данных поступает большое количество запросов.,Оказывает огромное давление.

решение：

• Добавляйте случайные значения в TTL разных Ключей
• Используйте кластер Redis для повышения доступности сервисов. Режим охраны, режим кластера
• Добавить текущую политику ограничения на понижение версии в кэш-сервис nginx — облачный шлюз Spring
• Добавьте несколько уровней в свой бизнес Гуава или кофеин

Подвести итог

• лавина кэша означает, что срок действия большого количества кэш-ключей истекает одновременно (один и тот же срок действия используется при настройке кэша Вызвано) или простоем службы Redis, что приводит к поступлению большого количества запросов на базу. данных, оказывает большое давление.и Разбивка кэшаразница：лавинаэто многоkey,авария Это определенныйkeyкэш
• Решение:
  • Добавляйте случайные значения в TTL разных Ключей,Волякэш Когда недействительно间分散开
  • Используйте кластер Redis для повышения доступности сервисов.
  • Добавить текущую политику ограничения на понижение версии в кэш-сервис Понижение рейтинга может использоваться в качестве стратегии достижения конечного результата системы, подходящей для проникновения, разрушения и лавинного лавинообразования.
  • Добавьте несколько уровней в свой бизнес

Тайник «Три брата»

Проникайте и создавайте ключи из воздуха, нулевая изоляция фильтра Блума.

Кэш отменяет ключи с истекшим сроком действия и решает проблему блокировок и неистечения срока действия.

У Avalanche большое количество ключей с истекшим сроком действия, и время истечения срока действия должно быть случайным.

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

5. Следует ли сначала удалить кэш или сначала изменить базу данных?

5.1 Проблемы существуют

Redis как кэш,mysqlданные如何иredisА как насчет синхронизации?（Двойная согласованность записи）

Определенно, определенно, определенноЧтобы установить помещение,Сначала представьсяДеловой фон Допускаются высокие требования к согласованности и постоянная задержка.

5.2 Двойное написание непротиворечиво

Согласованность двойной записи: при изменении данных базы данных одновременно необходимо обновить и кэшированные данные. Данные кэша и базы данных должны быть согласованными.

5.2.1 Распределенная блокировка

Распределенная блокировка Radisson обеспечивает согласованность данных,Сильная последовательность, низкая производительность。

• общая блокировка: блокировка чтения readLock,После блокировки,Другие потоки могут выполнять операции чтения.
• Эксклюзивная блокировка: также называется эксклюзивная блокировка writeLock. После блокировки она блокирует операции чтения и записи для других потоков.

5.2.2 Асинхронное уведомление

Асинхронные уведомления гарантируют конечную согласованность данных.

Асинхронное уведомление на основе MQ：

Асинхронное уведомление на основе канала：

• канал реализован на основе синхронизации master-slave MySQL
• Двоичный журнал (BINLOG) записывает все операторы DDL (язык определения данных) и операторы DML (язык манипулирования данными), но не включает операторы запроса данных (SELECT, SHOW).

5.3 Резюме

Redis используется в качестве кеша. Как синхронизировать данные MySQL с Redis? (согласованность двойной записи)

• Представьте бизнес в своем резюме,В то время мы сохраняли горячие данные статьи в кэш.,Хотя это горячие данные,ноТребования к реальному времени не так уж высоки、Синхронизация данных может иметь определенную задержку（Подходит для большинства предприятий）,所以我们когда时использовать的是асинхронный的方案同步данные（我们когда时использовать阿里的canalКомпоненты для синхронизации данных：Нет необходимости менять бизнес-код,Разверните службу каналов. Служба канала маскируется под подчиненный узел MySQL.,Когда данные MySQL обновляются,канал будет читать данные binlog,Затем получите данные через клиент канала,Просто обновите кэш)
• На тот момент мы сохранили инвентарь для выхвата купонов в кэш.,этотТребуется синхронизация данных в реальном времени.,дляОбеспечьте надежную согласованность данных,我们когда时использовать的是Блокировка чтения-записи, предоставляемая redissonдля обеспечения синхронизации данных（Добавляйте во время чтенияобщий Замок,Он может гарантировать, что чтение и чтение не являются взаимоисключающими, а чтение и запись — взаимоисключающими при обновлении данных;,Добавить эксклюзивный замок,Чтение, письмо и чтение являются взаимоисключающими понятиями.,Это может гарантировать, что другие потоки не смогут читать данные во время записи данных.,(Это делается во избежание потери данных. Обратите внимание, что метод чтения и метод записи должны использовать одну и ту же блокировку)

Пополнить:

Как эта эксклюзивная блокировка обеспечивает взаимное исключение чтения, записи и чтения? —— Фактически, нижний уровень эксклюзивной блокировки использует setnx, который гарантирует, что только один поток может одновременно управлять блокировкой.

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

Затем вы представите асинхронное решение (вы представите решение повторной блокировки чтения и записи)

• Разрешить услуги с постоянными задержками,использоватьасинхронныйуведомить
  • Использование промежуточного MQ Intermediate программное обеспечение,После обновления данных,Уведомление кэш Удалить
  • Используйте канал Али, промежуточное программное обеспечение,Нет необходимости изменять бизнес-код,Притворитесь подчиненным узлом MySQL,канал обновляет кэш, читая данные бинлога
• Сильно последовательный,использоватьRedisson提供的读写Замок
  • общая блокировка: блокировка чтения readLock,После блокировки,Другие потоки могут выполнять операции чтения.
  • Эксклюзивная блокировка: также называется эксклюзивная блокировка writeLock. После блокировки она блокирует операции чтения и записи для других потоков.

6. Персистентность Redis — Redis как кеш, как сохранить данные

Redis предоставляет два метода сохранения данных: 1.RDB 2.AOF.

6.1 RDB

6.1.1 Введение в РБД

Полное имя RDB — файл резервной копии базы данных Redis (файл резервной копии данных Redis), также называемый моментальным снимком данных Redis. Проще говоря, все данные, находящиеся в памяти, записываются на диск. Когда экземпляр Redis выходит из строя и перезапускается, файл моментального снимка считывается с диска, и данные восстанавливаются.

Redis имеет внутренний механизм запуска RDB, который можно найти в файле redis.conf. Формат следующий:

6.1 2 Принцип работы РБД

Когда запускается bgsave, он разветвляет основной процесс и получает дочерний процесс.,дочерний процессобщийДанные основной памяти процесса。ЗаканчиватьforkЗатем прочитайте данные памяти и напишите RDB документ. Fork использует технологию копирования при записи:

• Когда основной процесс выполняет операцию чтения,Доступ к общей памяти;
• Когда основной процесс выполняет операцию записи, копия данных будет скопирована и будет выполнена операция записи.

6.2 AOF

AOF означает «Добавить только файл». Каждая команда записи, обработанная Redis, будет записана в файл AOF, который можно рассматривать как файл журнала команд.

По умолчанию AOF отключен. Чтобы включить AOF, вам необходимо изменить файл конфигурации redis.conf:

Файлы AOF обычно хранятся в рабочем каталоге сервера Redis, а имя файла — Appendonly.aof.

Частоту записи команд AOF также можно настроить через файл redis.conf:

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

Redis также автоматически перезапишет файл AOF при срабатывании порога. Пороги также можно настроить в redis.conf:

6.3 Сравнение RDB и AOF

У RDB и AOF есть свои преимущества.,Если у вас повышенные требования к безопасности данных,В реальном развитии частообъединить两ВОЗ来使用。

6.4 Резюме

Поскольку Redis служит кешем, как сохраняются данные?

Redis предоставляет два метода сохранения данных: 1.RDB 2.AOF.

В чем разница между двумя методами сохранения RDB и AOF?

• RDB — это файл моментального снимка, который записывает данные, хранящиеся в памяти Redis, на диск. Когда экземпляр Redis восстанавливает данные, удобно восстановить данные из файла моментального снимка RDB.
• Смысл AOF заключается в добавлении файла. Когда Redis работает и записывает команду, она будет сохранена в этом файле (обычно он хранится в рабочем каталоге сервера Redis, имя файла — Attachonly.aof). восстанавливает данные, он снова выполнит команду из этого файла, чтобы восстановить данные

Какой из этих двух методов восстанавливается быстрее?

RDB — это двоичный файл.,Размер также относительно небольшой при сохранении.,Он восстанавливается быстрее,но它有可能会丢数据；Мы в проектеAOF также обычно используется для восстановления данных.,Хотя скорость восстановления AOF несколько,Но риск потери данных гораздо меньше,Вы можете установить стратегию очистки диска в файле AOF.,В то время мы настроили пакетную обработку команд записи один раз в секунду.

7. Стратегия истечения срока действия данных Redis

Если срок действия ключа Redis истечет, он будет немедленно удален?

set key value [EX seconds] [PX milliseconds] [NX|XX]
set name jw 10

Redis устанавливает время действия данных. По истечении срока действия данные необходимо удалить из памяти. Удаление может осуществляться по разным правилам. Это правило удаления называется политикой удаления данных (политикой истечения срока действия данных). Ленивое удаление, обычное удаление

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

Ленивое удаление: после установки срока действия ключа оставляем его в покое. Когда ключ нужен, проверяем, истек ли срок его действия, удаляем его, в противном случае ключ возвращается.

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

7.2 Обычное удаление

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

Существует два режима периодической очистки:

• Режим SLOW — это запланированная задача. Частота выполнения по умолчанию составляет 10 Гц и не превышает 25 мс каждый раз. Это число можно настроить, изменив параметр hz в файле конфигурации redis.conf.
• Частота выполнения режима FAST не фиксирована, но интервал между двумя запусками составляет не менее 2 мс, а каждый раз занимает не более 1 мс.

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

недостаток：Трудно определить, как долго и как часто выполняются операции удаления.。

Redisполитика удаления по истечении срока действия：Ленивое удаление + Удалять регулярно Две стратегии используются вместе

7.3 Резюме

Каковы стратегии истечения срока действия данных Redis?

В Redis предусмотрены две стратегии удаления данных по истечении срока действия:

• Первый — сентиментальное удаление. После установки срока действия ключа оставляем его в покое. Когда ключ нужен, проверяем, истек ли срок его действия, в противном случае ключ возвращается.
• Второй - Удалять регулярно,То есть время от времени,Давайте проверим некоторые ключи,Удалить просроченные ключи внутри

Два режима для регулярной уборки.：

• Режим SL0W является запланированной задачей. Частота выполнения по умолчанию составляет 10 Гц и не превышает 25 мс каждый раз. Это число можно настроить, изменив параметр hz в файле конфигурации redis.conf.
• Частота выполнения режима FAST не фиксирована. Каждый цикл событий пытается выполниться, но интервал между двумя попытками составляет не менее 2 мс, и каждый раз занимает не более 1 мс.

Redisполитика удаления по истечении срока действия：Ленивое удаление + Удалять регулярно Две стратегии используются вместе。

8. Стратегия удаления данных Redis

Что делать, если кешей слишком много, память ограничена, а память заполнена? ——На самом деле, я просто хочу спросить, какова стратегия удаления данных в Redis?

Стратегия устаревания данных：когдаRedisКогда не хватает памяти в,В это время в Redis добавляется новый ключ.,Затем Redis удалит данные в памяти по определенному правилу.,Это правило удаления данных называется удалением памяти.

8.1 Восемь стратегий удаления данных

Redis поддерживает 8 различных стратегий выбора ключей для удаления:

• noeviction: не удалять никакие ключи,Однако запись новых данных не допускается, если память заполнена.,Это стратегия по умолчанию
• Летучие-ttl: Для ключа с установленным TTL сравните оставшееся значение TTL ключа. Чем меньше TTL, тем раньше он будет удален.
• allkeys-random: случайным образом удалить все ключи.
• Летучий-случайный: Случайно удалять ключи с установленным TTL.
• allkeys-lru: удалить все ключи на основе алгоритма LRU.
• Летучие-lru: Удалить ключи с установленным TTL на основе алгоритма LRU.
• allkeys-lfu: удалить все ключи на основе алгоритма LFU.
• Летучий-lfu: Удалить ключи с установленным TTL на основе алгоритма LFU.

файл redis.conf

# The default is:
#
# maxmemory-policy noeviction

LRU（Least Recently Used）Последний раз использовался。用когда前时间减去最后一次访问时间,Чем больше значение, тем выше приоритет устранения.

LFU（Least Frequently Used）наименее часто используемый。посчитаю каждыйkeyчастота доступа,Чем меньше значение, тем выше приоритет устранения.

LRU: доступ к ключу 1 осуществлялся до 3 с, доступ к ключу 2 осуществлялся до 9 с, а ключ 2 был удален.

LFU: ключ 1 посещался 4 раза за последние 5 с, ключ 2 посещался 9 раз за последние 5 с, а ключ 1 удален.

8.2 Стратегия устаревания данных – рекомендации по использованию

1. приоритетное использование allkeys-lru Стратегия. В полной мере использовать LRU Преимущества алгоритмов,Храните данные, к которым вы недавно обращались, в кэше. Если в бизнесе есть очевидное различие между горячими и холодными данными,Рекомендуется.
2. Если в бизнесе существует небольшая разница в частоте доступа к данным и нет очевидного различия между «горячими» и «холодными» данными, рекомендуется использовать случайные ключи, а затем случайным образом выбирать и удалять их.
3. Если в бизнесе есть необходимость придерживаться вершины, вы можете использовать стратегию Volat-lru. В то же время, если для топ-данных не установлен срок действия, данные никогда не будут удалены, как и другие данные. срок годности будет устранен.
4. Если в бизнесе есть краткосрочные и часто используемые данные, вы можете использовать стратегию allkeys-lfu или volbaty-lfu.

8.3 Другие вопросы интервью о стратегиях удаления данных

1) В базе данных содержится 10 миллионов данных, а Redis может кэшировать только 200 000 данных. Как гарантировать, что данные в Redis являются горячими данными?

Используя стратегию исключения allkeys-lru (выберите для удаления наименее использованные данные), то, что остается, является часто используемыми горячими данными.

2) Что происходит, когда Redis не хватает памяти?

Какова стратегия удаления данных? Если это конфигурация по умолчанию (noeviction), об ошибке будет сообщено напрямую.

8.4 Резюме

1) Каковы стратегии удаления данных Redis?

Redis предоставляет 8 стратегий удаления данных (noeviction, Летучие-ttl, allkeys-random, allkeys-random, allkeys-lru, летучих-lru, allkeys-lfu, летучих-lfu). По умолчанию используется noeviction, который не удаляет никакие данные. Внутренний. Если этого недостаточно, об ошибке будет сообщено напрямую; ее можно установить в файле конфигурации Redis;

В нем есть два очень важных понятия: одно — LRU, а другое — LFU.

• LRU означает последнее использование, вычитая время последнего доступа из текущего времени. Чем больше значение, тем выше приоритет удаления.
• LFU означает наименьшую частоту использования. Будет учитываться частота доступа каждого ключа. Чем меньше значение, тем выше приоритет устранения.

Allkeys-lru часто используется в процессе разработки (на основе собственных бизнес-сценариев).

В проекте мы настроили allkeys-lru, который выбирает для удаления наименее используемые данные и оставляет некоторые часто используемые ключи в Redis.

2) В базе данных содержится 10 миллионов данных, а Redis может кэшировать только 200 000 данных. Как гарантировать, что данные в Redis являются горячими данными?

Используя стратегию исключения allkeys-lru (выберите для удаления наименее использованные данные), то, что остается, является часто используемыми горячими данными.。

3) Что происходит, когда Redis не хватает памяти?

Какова стратегия удаления данных? Если это конфигурация по умолчанию (noeviction), об ошибке будет сообщено напрямую.。

Справочные видео и заметки, связанные с Dark Horse Programmer