Кэш Три проблемы и решения

1. Источник кеша

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

2. Проблемы с кешем

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

2.1 Проникновение в кэш

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

2.2 Решения

Решения для проникновения в кеш в отрасли относительно зрелые, и наиболее часто используемые из них следующие:

• Фильтр Блума: алгоритм, аналогичный хеш-таблице, генерирует битовую карту со всеми возможными условиями запроса и использует эту битовую карту для фильтрации перед запросом к базе данных.Если его нет в ней, он фильтруется напрямую, тем самым снижая нагрузку на базу данных. уровень.
  
• Кэш нулевого значения: относительно простое решение.После запроса несуществующих данных в первый раз ключ и соответствующее нулевое значение также помещаются в кеш, но устанавливаются на более короткое время недействительности, например, несколько минут, поэтому что он может справиться с большим количеством атак на ключ за короткий период времени.Установка короткого времени недействительности связана с тем, что значение может быть нерелевантным для бизнеса и иметь мало смысла, и этот запрос может быть инициирован не злоумышленником .Хранить нужно долго, так может истечь раньше.

2.3 Лавина кэша

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

2.4 Решения

• Взаимное исключение потоков: только один поток может строить кеш, а другие потоки ждут завершения выполнения потока, который строит кеш, а затем повторно извлекают данные из кеша.Только один поток выполняет запрос в каждый момент времени , что снижает нагрузку на дб, но и недостатки очевидны. , что снижает qps системы.
  
• Ступенчатое время аннулирования: этот метод относительно прост и груб. Поскольку одновременное аннулирование вызовет слишком много лавин запросов, мы можем избежать этой проблемы с определенной продолжительности, разбивая разные времена аннулирования. При установке времени аннулирования в кеше, случайное время из соответствующего диапазона значений может быть использовано в качестве времени отказа.

2.5 Разбивка кеша

Нарушение кеша на самом деле является частным случаем лавины кеша. Любой, кто использовал Weibo, должен знать, что Weibo имеет функцию горячих тем, и объем поиска пользователей по горячим темам в некоторые моменты часто намного выше, чем по другим темам. пятно" системы. Поскольку кэш данных этих горячих точек в системе также имеет время аннулирования, когда кеш горячих точек достигает времени аннулирования, в это время в систему все еще может поступать большое количество запросов, и нет слой кэша.Для защиты эти запросы также будут достигать БД и могут вызвать сбои. Разница между разбивкой и лавиной заключается в том, что разбивка предназначена для данных конкретной точки доступа, а лавина — для всех данных.

2.6 Решения

• Кэш уровня 2. Выполните кэширование уровня 2 для горячих данных и задайте разное время аннулирования для разных уровней кэша, чтобы запросы не проникали напрямую через уровень кэша для достижения базы данных.
  
• упоминается здесьРешение Alibaba для разбивки кеша удваивает 11 триллионов трафика, ключ к решению этой проблемы лежит в доступе к точке доступа. Поскольку горячие точки могут меняться со временем, специальное кэширование фиксированных данных не может устранить основную причину.Алгоритм LRUЭто может помочь нам решить эту проблему лучше. Итак, что такое LRU, давайте кратко представим его, если вам интересно, вы можете щелкнуть ссылку выше, чтобы просмотреть его.
  
• LRUАлгоритм (наименее недавно использованный, наименее недавно использованный) исключает данные на основе исторических записей доступа к данным. Основная идея заключается в том, что «если доступ к данным был осуществлен недавно, вероятность доступа к ним в будущем также выше». Наиболее распространенной реализацией является использование связанного списка для хранения кэшированных данных, как показано на следующем рисунке.
  Этот связанный список является нашей структурой кеша, а этапы обработки кеша таковы:
• Сначала поместите новые данные в начало связанного списка.
• В процессе вставки данных, если обнаруживается, что в связанном списке есть данные, к которым осуществляется повторный доступ, то есть есть запрос на повторный доступ к данным, то заголовок вставляемого связанного списка, т.к. горячие данные по сравнению с другими данными, имеют значение сохранения дольше
• Наконец, когда данные связанного списка заполнены, данные в нижней части удаляются, то есть данные, к которым редко обращаются.

• Алгоритм LRU-K, по сути, приведенный выше алгоритм также является частным случаем этого алгоритма, а именно LRU-1.Вышеприведенный алгоритм имеет много иррациональностей.В реальном процессе применения алгоритм совершенствуется.Например, случайное влияние данных будет Вызывает низкий показатель попаданий, например, определенные данные вот-вот достигнут дна и вот-вот будут удалены, но поскольку в заголовок снова помещается запрос, а после этого запроса на данные нет, на самом деле это неразумно, чтобы данные продолжали существовать.В таких случаях алгоритм LRU-K имеет лучшее решение. Структурная схема выглядит следующим образом:

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

• Первый шаг — добавить данные и поместить их в начало первой очереди.
• Если к данным в очереди не обращались K раз (значение определяется в соответствии с конкретным системным qps), они будут продолжать достигать конца связанного списка до тех пор, пока не будут исключены; если к данным обращались K раз в очереди очередь, она будет добавлена ​​в связанный список В следующем двухуровневом (в частности, сколько уровней структуры также требуется для системного анализа), они расположены в связанном списке на двух уровнях в хронологическом порядке.
• Операция в следующем двухуровневом связанном списке такая же, как описанный выше алгоритм.Если данные в связанном списке будут доступны снова, они будут перемещены в начало.Когда связанный список заполнен, нижние данные будут удалены .

参考文章： 双11万亿流量下的分布式缓存 https://yq.aliyun.com/articles/290865
          缓存淘汰算法 http://flychao88.iteye.com/blog/1977653