1. Причина кеширования.
С постепенным улучшением развития Интернет-системы, количество запросов в секунду в системе было улучшено. В большинстве существующих систем добавлен механизм кэширования, чтобы избежать чрезмерных запросов на прямые операции с базой данных и вызвать узкие места в системе, что значительно улучшает Пользовательский опыт и стабильность системы.
2. Проблема
с кешем. Хотя использование кеша привело к определенным качественным улучшениям в системе, оно также создает некоторые проблемы, требующие внимания.
2.1 Проникновение кеша
Проникновение кэша относится к запросам данных, которые не должны существовать, потому что нет информации о данных в кеше, они перейдут непосредственно на уровень базы данных для запроса, с системного уровня, кажется, что он проникает на уровень кеша и напрямую достигает БД. Для проникновения в кэш без защиты уровня кеша такие данные запроса, которые не должны существовать, могут представлять опасность для системы. Если кто-то злонамеренно использует такие несуществующие данные для частого запроса системы, нет, точно Утверждается, что для атаки на систему запрос достигнет уровня базы данных, что приведет к сбою базы данных и отказу системы.
2.2 Решение
Решения для проникновения в кэш в отрасли являются относительно зрелыми, и наиболее часто используются следующие решения:
Фильтр Блума: алгоритм, похожий на хэш-таблицу, который использует все возможные условия запроса для генерации растрового изображения, которое используется для фильтрации перед запросом к базе данных, и если его нет в нем, он фильтрует напрямую, тем самым снижая нагрузку на уровень базы данных. Алгоритм BloomFilter реализован на гуаве.
Кэш нулевого значения: относительно простое решение. После запроса несуществующих данных в первый раз ключ и соответствующее нулевое значение также помещаются в кеш, но для них устанавливается более короткий срок действия, например Несколько минут, чтобы вы могли справиться с большим количеством атак на ключ за короткий период времени. Установите более короткий срок действия, потому что значение может не иметь отношения к бизнесу и не имеет большого значения, а запрос может быть инициирован злоумышленником. Необходимо долгосрочное хранение, поэтому оно может истечь раньше.
2.3 Cache Avalanche
В обычных системах кэширования, таких как redis, memcache и т. Д., Мы устанавливаем время аннулирования для кеша, но если все кеши имеют одинаковое время аннулирования, тогда все системные запросы будут отправляться на уровень базы данных, когда срок их действия истекает одновременно. db может быть не в состоянии выдержать такое большое давление и вызвать сбой системы.
2.4 Решение
Взаимное исключение потоков: пусть только один поток создает кеш, а другие потоки ждут выполнения потока, который создает кеш, а затем снова получают данные из кеша. Только один поток выполняет запрос за раз, что снижает нагрузку на db, но недостатки также очевидны , Уменьшите qps системы.
Поэтапное время аннулирования: этот метод относительно прост и груб. Поскольку одновременное аннулирование приведет к лавине слишком большого количества запросов, мы можем избежать этой проблемы с определенной продолжительности, смещая различные времена аннулирования. Когда установлено время аннулирования кеша , В качестве времени отказа можно использовать случайное время из подходящего диапазона значений.
2.5 Разбивка кеша
Разрушение кеша на самом деле является частным случаем лавины кеширования.Каждый, кто использовал Weibo, должен знать, что Weibo имеет функцию горячих тем, и объем поиска пользователей по горячим темам в некоторые моменты часто намного выше, чем по другим темам. Мы стали «горячей точкой» системы. Поскольку кэш данных этих точек доступа в системе также имеет время аннулирования, когда кеш точки доступа достигает времени аннулирования, большое количество запросов все еще может достигать системы в это время, и уровень кеширования отсутствует. Защита, эти запросы также попадут в базу данных и могут вызвать сбои. Разница между поломкой и лавиной заключается в том, что поломка относится к конкретным горячим данным, а лавина - ко всем данным.
2.6 Решение
Кэш второго уровня: выполните кэширование второго уровня для горячих данных и установите разное время аннулирования для разных уровней кеша, чтобы запрос не проникал напрямую через слой кеша для достижения базы данных.
Вот ссылка на решение Али для разбивки кэша двойного 11 триллиона трафика.Ключ к решению этой проблемы - доступ к точкам доступа. Поскольку «горячие точки» могут со временем меняться, специальное кэширование фиксированных данных не может решить эту проблему. Комбинация алгоритма LRU может лучше помочь нам решить эту проблему.
Алгоритм LRU (наименее недавно использованный, наименее недавно использованный) удаляет данные на основе исторических записей доступа к данным. Его основная идея заключается в том, что «если к данным был осуществлен доступ в последнее время, вероятность доступа в будущем также выше». Наиболее распространенная реализация - использовать связанный список для хранения кэшированных данных, как показано на следующем рисунке.
Этот связанный список является нашей структурой кеша, и шаги обработки кеша
Сначала поместите новые данные в начало связанного списка
В процессе вставки данных, если обнаруживается, что в связанном списке есть данные, к которым осуществляется повторный доступ, то есть запрашивается повторный доступ к данным, затем вставляется заголовок связанного списка, потому что они могут быть горячими данными по сравнению с другими данными, с Значение более длительного удержания
Наконец, когда данные связанного списка заполнены, нижние данные удаляются, то есть данные, к которым не часто обращаются.
Алгоритм LRU-K, по сути, вышеупомянутый алгоритм также является частным случаем алгоритма, а именно LRU-1. Вышеупомянутый алгоритм имеет много иррациональностей. В реальном процессе приложения алгоритм используется для улучшения, например, случайного воздействия данных. Это приводит к низкому показателю попаданий. Например, некоторые данные вот-вот достигнут дна и будут удалены, но поскольку запрос помещается в заголовок, после этого запроса данных нет, то дальнейшее существование данных на самом деле необоснованно. В этом случае алгоритм LRU-K имеет лучшие решения. Структурная схема выглядит следующим образом:
LRU-K необходимо поддерживать одну или несколько очередей для записи истории всех кэшированных данных, к которым осуществляется доступ. Только когда количество обращений к данным достигает K раз, данные помещаются в кэш. Когда данные необходимо удалить, LRU-K удалит данные, K-е время доступа которых является наибольшим с текущего времени.
Первый шаг - добавить данные в начало первой очереди.
Если к данным не обращались K раз в очереди (значение определяется конкретной системой qps), они будут продолжать достигать нижней части связанного списка, пока не будут удалены; если к данным обращались K раз, пока они находились в очереди, они будут добавлены в На следующем уровне 2 (в частности, несколько уровней структуры также объединены с системным анализом) связанный список, расположенный в связанном списке второго уровня в хронологическом порядке
Операция в следующем связанном списке уровня 2 такая же, как и в описанном выше алгоритме. При повторном доступе к данным в связанном списке он переместится в начало. Когда связанный список заполнится, нижние данные будут удалены.
По сравнению с LRU, LRU-K должен поддерживать дополнительную очередь для записи истории всех кэшированных данных, к которым осуществляется доступ, поэтому для создания кеша требуется больше места в памяти, но преимущества также очевидны, и данные лучше сокращаются. Уровень загрязнения увеличивает частоту попаданий в кэш.Это также способ для системы обменять определенную стоимость оборудования на производительность системы. Конечно, существуют более сложные алгоритмы структуры кеша, которые можно изучить, щелкнув алгоритм LRU, например, две очереди и множественные очереди и т. Д. В этой статье они не будут повторяться, а только предоставить читателям решение.
Перепечатано по ссылке : https://gper.club/articles/7e7e7f7ff4g5bgc7g6f