Проникновение кэша Redis, лавина, интерпретация поломки

Когда мы запрашиваем запись, мы сначала делаем запрос в Redis, а затем в MySQL и обнаруживаем, что запись не может быть найдена , но запрос каждый раз попадает в базу данных, что приводит к резкому увеличению нагрузки на фоновую базу данных. похожи на «проникновение». «Он попадает в базу данных напрямую, как если бы она была кэширована. Это явление называется проникновением в кэш. Это явление называется проникновением кэша, и этот редис становится украшением.

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

решение

Вариант 1. Пустой кэш объектов или значение по умолчанию.

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

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

Вариант 2: фильтр Блума

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

Фильтр Блума был предложен Блумом в 1970 году. На самом деле это длинный двоичный вектор и серия функций случайного отображения. Фильтры Блума можно использовать для определения того, находится ли элемент в коллекции.

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

Разбивка кэша

определение

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

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

Когда пришло время, его, естественно, расчистили, но его все равно посещали.

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

решение

Решение 1. Срок действия данных точки доступа никогда не истекает

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

Решение 2. Взаимоисключающая эксклюзивная блокировка для предотвращения поломки

Используя идею распределенной блокировки, гарантируется, что для каждого ключа только один поток одновременно запрашивает внутреннюю службу. Пока определенный поток запрашивает внутреннюю службу, другие потоки не имеют разрешения на получить распределенную блокировку и нужно подождать.После запроса они вернут Write to Redis, а другие потоки запросов будут выполнять запросы в Redis.Конечно, это приведет к ухудшению производительности системы.

Пример Java-кода выглядит следующим образом:

public User findUserById2(Integer id) {
    User user = null;
    String key = CACHE_KEY_USER+id;

    //1 先从redis里面查询,如果有直接返回结果,如果没有再去查询mysql
    user = (User) redisTemplate.opsForValue().get(key);
    if(user == null) {
        //2 大厂用,对于高QPS的优化,进来就先加锁,保证一个请求操作,让外面的redis等待一下,避免击穿mysql
        synchronized (UserService.class){
            user = (User) redisTemplate.opsForValue().get(key);
            //3 二次查redis还是null,可以去查mysql了(mysql默认有数据)
            if (user == null) {
                //4 查询mysql拿数据
                user = userMapper.selectByPrimaryKey(id);//mysql有数据默认
                if (user == null) {
                    return null;
                }else{
                    //5 mysql里面有数据的,需要回写redis,完成数据一致性的同步工作
                    //setnx 不存在才创建
                    redisTemplate.opsForValue().setIfAbsent(key,user,7L,TimeUnit.DAYS);
                }
            }
        }
    }
    return user;
}

лавина кэша

определение

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

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

решение

Вариант 1. Установите время истечения срока действия случайным образом.

Добавьте случайное значение к исходному времени отказа, например 1–5 минут случайным образом. Это позволяет избежать лавин кэша, вызванных использованием одного и того же срока действия.

Вариант 2. Прогрев кэша

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

Вариант 3. Кластер Redis

Чтобы предотвратить лавину кэша, вызванную простоем Redis, вы можете создать кластер Redis, чтобы повысить устойчивость Redis к катастрофам.