Лекция
Привет, Вы узнаете о том , что такое виды кеширования, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое виды кеширования, кеширование, кеш , настоятельно рекомендую прочитать все из категории Высоконагруженные проекты.Паралельные вычисления. Суперкомпьютеры. Распределенные системы.
Кэш или кеш (англ. cache, от фр. cacher — «прятать»; произносится [kæʃ] — «кэш») — промежуточный буфер с быстрым доступом к нему, содержащий информацию, которая может быть запрошена с наибольшей вероятностью. Доступ к данным в кэше осуществляется быстрее, чем выборка исходных данных из более медленной памяти или удаленного источника, однако ее объем существенно ограничен по сравнению с хранилищем исходных данных.
Кэширование позволяет увеличивать производительность веб-приложений за счет использования сохраненных ранее данных, вроде ответов на сетевые запросы или результатов вычислений. Благодаря кэшу, при очередном обращении клиента за одними и теми же данными, сервер может обслуживать запросы быстрее. Кэширование — эффективный архитектурный паттерн, так как большинство программ часто обращаются к одним и тем же данным и инструкциям. Эта технология присутствует на всех уровнях вычислительных систем. Кэши есть у процессоров, жестких дисков, серверов, браузеров.
В первую очередь, хотелось бы пояснить, что кэширование – это одна из наиболее важных составляющих любого проекта. В частности, это единственный способ сделать больше и быстрее при использовании ограниченных ресурсов. А, как известно, ресурсы всегда ограничены: как серверные, так и пользовательские.
Кеш приближает данные к месту их использования. В современном мире, состоящим на 98% из интернета, данные обычно лежат очень далеко от пользователя. На всем пути от хранилища к пользователю есть кеши, которые служат только одной цели – чтобы пользователь как можно быстрее получил свои данные.
Если рассмотреть внимательнее, то видно, что драгоценное время тратится на обработку данных в поставщике и передачу данных от поставщика клиенту, время обработки данных на клиенте тут не учитываем.
При наличии высоких нагрузок
кеширование просто необходимо. Оно позволяет обслуживать больше клиентов, с теми же ресурсами, потому что поставщики данных больше отдыхают. Но даже при невысоких нагрузках кеширование положительно влияет на отзывчивость приложения.
Одно из основных заблуждений насчет кеширования заключается в том, что многие думают что кеш можно просто включить.
На заре своей карьеры программиста я один раз просто так включил кеширование, буквально через час пришлось его выключить. Тогда я нарвался на основную проблему при кешировании – устаревание данных. Пользователь после изменения данных не видел результата 15 минут.
Очень важно понимать что и как вы собираетесь кешировать, чтобы не нарушать логику работы приложения. И первый вопрос, на который вам необходимо ответить – насколько устаревшие данные можно отдавать клиенту. Естественно можно сделать свой кеш для каждого клиента, это упростит решение вопроса об актуальности данных, но принесет много других проблем.
При кэшировании данных, как правило, не возникает проблем в их сохранении и повторном использовании. Основная проблема заключается в том, что бы определить, когда кэш утрачивает свою актуальность. То есть определить, можно ли использовать данные из кэша, или необходимо вычислить эти данные заново, поскольку что-то могло измениться. Это я назову проблемой актуальности кэша (терминология моя).
Второй проблемой кэширования является проблема быстродействия. А не выполняются ли наш алгоритм без кэширования быстрее, чем с кэшированием? Несмотря на абсурдность с первого взгляда, она более чем имеет место. Дело в том, что алгоритмы кэширования тоже потребляют ресурсы, и запросто может случиться так, что количество потребляемых кэшем ресурсов превышает количество ресурсов для вычисления самих данных. Это часто случается в 2-х случаях. Первый случай — это когда сайт из 10-ти страниц сажают на мощный фреймворк. Тут все просто – исходных данных настолько мало, что скорость вычисления очень высока, а кэширование только тормозит работу. Второй случай обратный — когда сайт настолько большой, что размер кэша вырастает до объемов приводящих к существенному замедлению их поиска в кэше.
Добиться решения обоих проблем невозможно. Возможно лишь выбрать метод обеспечивающие максимальное быстродействие. А еще лучше – что бы это метод выбирался автоматически.
Проблема быстродействия не так актуальна, и решается либо отключением использования кэширования в конфигурации, либо периодического физического удаления закешированных данных и переход на более быстродействующее оборудование.
А вот что касается проблемы актуальности, тут все намного сложнее…
Автор различает 4 основных типа кэширования информации:
1. Независимый или статичный – имеет место, когда не требуется проверка изменился ли объект. Алгоритм прост – если есть данные в кеше, то отдать данные, иначе их вычислить. Эффективно в рамках работы одного процесса, когда требуется частое использование результатов сложных промежуточных вычислений. После завершения процесса статичный кэш умирает и для повторного процесса все данные вычисляются вновь. Вобщем-то в любом языке программирования все временные переменные – ни что иное, как статичный кеш. Если же требуется кэширование результатов функции, то можно использовать такой алгоритм с использованием static-переменных на примере PHP:
function getData($id)
{
static $data = array();
if (isset($data[$id])) return $data[$id];
// вычисление данных
$data[$id] = $newData;
return $data[$id];
}
2. Явно-зависимый – имеет место, когда решение об обновлении кэша принимается по некоторому легко вычисляемому признаку. Сюда относится прежде всего кэширование данных взятых из определенного файла, а так же кэширование по времени. В этих случаях легко определить изменился ли файл или не истекло ли время существования кэша (и кэш явно зависит от этих факторов). Алгоритмы здесь тоже достаточно простые – сводятся к проверкам условий, но в отличие от статического кэша он может независимо использоваться разными процессами.
3. Неявно-зависимый – имеет место, когда изменение объекта кэширования зависит от множества факторов. Например, в состав объекта входит множество других объектов, которые тоже могут изменяться. То есть объект неявно (не на прямую) зависит от других, которые тоже могут зависеть от других и т.д. Совокупность этих факторов является неявными зависимостями объекта, и что бы принять решение о том, изменился ли объект нужно «опросить» их все, что не всегда возможно или целесообразно. Например, функция, которая показывает информацию, взятую из базы данных. Мы можем закешировать результат функции, но мы должны знать, когда данные изменятся, что бы их обновить. А это эквивалентно обращению к таблице, что по ресурсоемкости равносильно выполнению функции. А если таблиц много? Смысл кэша теряется.
Это раскрывается через так называемую «таблицу зависимостей». В этой таблице присутствует 2 столбца: объекты и время их изменения. При изменении объектов необходимо обновлять их времена в таблице. Скорость доступа к самой таблице очень высока, (как правило, она находится в статичном или явно-зависимом кеше), и получить времена изменения всех необходимых нам объектов можно очень быстро. И если хоть одно время изменения нужных объектов превышает время кэширования, то кэш необходимо сбросить. Таким образом, неявные зависимости превращаются в явные – объект зависит от некоторого набора времен в таблице зависимостей.
Приведу пример. Есть некий модуль CMS, который занимается отображением комментариев. У нас есть 2 таблицы в БД – пользователей и комментариев, которые связаны соотношением один-ко-многим. При изменении данных некоторого пользователя, мы устанавливаем текущее время в строке «users» в таблице зависимостей. Если изменились комментарии, мы аналогично поступаем со строкой «comments». Модуль знает, что он зависит от «users» и «comments» и если время хотя бы одного из них превышает время изменения кэша, то кэш сбрасывается, иначе — используется. Обращу внимание на то, что «users» и «comments» — это не обязательно время изменения таблицы, это скорее времена изменения некоторой сущности, которая может состоять из множества таблиц и других параметров.
4. Условно-зависимый – имеет место, когда неявно-зависимый кэш может быть приведен к явно-зависимому или статичному при выполнении некоторого условия. Например, можно утверждать, что время последнего изменения таблицы зависимостей – это время последнего изменения данных на сайте. Если для пользователя на странице нет уникальных данных (читай – он не залогинен), то вся страница будет зависеть только от таблицы зависимостей. А значит, всю страницу целиком можно положить в кэш, на данном условии. Сюда же относится кэш, который в нужный момент просто физически удаляется.
Есть три основных типа кеширования по механике работы:
Наверное можно придумать и другие типы кешей, но я не встречал.
Объем кеша всегда ограничен. Зачастую он меньше объема данных, которые в этот кеш можно положить. Поэтому элементы, помещенные в кеш, рано или поздно будут вытеснены. Современные фреймворки для кеширования позволяют очень гибко управлять устареванием, учитывая приоритеты, время устаревания, объемы данных итд.
Если одни и те же данные попадают в разные кеши, то возникает проблема когерентности кеша. Например одни и те же данные используются для формирования разных страниц и кешируются страницы. Страницы сформированные позже будут содержать обновленные данные, а страницы, закешированные раньше, будут содержать устаревшие данные. Таким образом будет нарушена согласованность поведения.
Простой способ поддержания когерентности – принудительное устаревание (сброс) кеша при изменении данных. Поэтому увеличение памяти для кеша, чтобы он меньше устаревал, не всегда хорошая идея.
Основной параметр, который характеризует систему кеширования – это процент попаданий запросов в кеш. Этот параметр довольно легко измерить, чтобы понять насколько ваша система кеширования эффективна.
Частые сбросы кеша, кеширование редко запрашиваемых данных, недостаточный объем кеша – все это ведет к пустой трате оперативной (обычно) памяти, не повышая эффективность работы.
Иногда данные меняются настолько часто и непредсказуемо, что кеширование не даст эффекта, процент попаданий будет близок к нулю. Но обычно данные считываются гораздо чаще, чем записываются, поэтому кеши эффективны.
Это самый полезный тип кеширования, так как отдает свежие данные и позволяет реализовать многоуровневый кеш.
Такой тип кеширования встроен в протокол HTTP. Сервер отдает метку изменения, а клиент кеширует у тебя результат и в последующем запросе передает эту метку. Сервер может дать ответ, что состояние не изменилось и можно использовать кешированный на клиенте объект. Сервер в свою очередь, получив метку может переспросить у хранилища были ли изменения или нет.
Этот тип кеширования не избавляет от накладных расходов на общение между системами. Поэтому часто дополняется другими типами кеширования, чтобы ускорить работу.
Если есть система распределенного кеширования (memcached, Windows Sever App Fabric, Azure Cache), то можно использовать кеш сквозной записи. Рукопашная реализация синхронизации кешей между узлами сама по себе отдельный большой проект, поэтому не стоит заниматься ей в рамках разработки приложения.
Не стоит пытаться кешировать все в синхронизированном кеше, иначе большая часть кода приложения будет заниматься перестройкой кеша.
Также не стоит забывать что системы распределенного кеширования также требуют общения между системами, что может сказываться на быстродействии.
Выбирайте правильную гранулярность кешируемых данных. Например кеширование данных для каждого пользователя скорее всего будет неэффективно при большом количестве пользователей. Если кешировать данные для всех пользователей разом, то возникнут проблемы с устареванием данных и когерентностью кеша.
Кешируйте данные как можно позже, непосредственно перед отдачей во внешнюю систему. Кешировать данные, полученные извне, необходимо только в случае проблем с производительностью на этом этапе. Внешние хранилища, такие как СУБД и файловые системы, сами реализуют кеширование, поэтому обычно нет смысла кешировать результаты запросов.
Не нужно городить свои велосипеды для кеширования в приложениях, обычно уже есть готовые инструменты и надо уметь ими пользоваться.
Некоторый контент легче кэшировать. Об этом говорит сайт https://intellect.icu . Для большинства сайтов кэшировать лучше:
Эти элементы меняются нечасто, поэтому их можно кэшировать в течение более длительных периодов времени.
А эти элементы нужно кэшировать осторожно:
В дополнение к вышеуказанным общим правилам можно настроить политики, которые позволят вам соответствующим образом кэшировать различные типы контента. Например, если все авторизовавшиеся пользователи видят один и тот же вид сайта, может быть полезно кэшировать его. Если авторизовавшиеся пользователи видят пользовательский вид сайта, который будет действителен в течение некоторого времени, вы можете сохранить кэш в браузере пользователя, но исключить промежуточное кэширование.
Основной проблематикой кэширования является быстрота реакции на запросы к основным системам хранения и обработки входящей и исходящей структурированной информации.
Представьте, что необходимо осуществить быструю передачу информации, однако скорость доступа к данным крайне низкая. Или другая ситуация: скорость хорошая, но мало доступной памяти или ширина канала недостаточная, или процессорные и дисковые факторы мешают осуществить задачу. В этом случае кэширование – это единственный выход из ситуации.
Ник Карник, автор материала, перевод которого мы сегодня публикуем, предлагает поговорить о роли кэширования в производительности веб-приложений, рассмотрев средства кэширования разных уровней, начиная с самого низкого. Он обращает особое внимание на то, где именно могут быть кэшированы данные, а не на то, как это происходит.
Мы полагаем, что понимание особенностей систем кэширования, каждая из которых вносит определенный вклад в скорость реакции приложений на внешние воздействия, расширит кругозор веб-разработчика и поможет ему в деле создания быстрых и надежных систем.
Иерархия памяти
Начнем наш разговор о кэшах с самого низкого уровня — с процессора. Кэш-память процессора — это очень быстрая память, которая играет роль буфера между процессором (CPU) и оперативной памятью (RAM). Кэш-память хранит данные и инструкции, к которым обращаются чаще всего, благодаря чему процессор может получать ко всему этому доступ практически мгновенно.
В процессорах имеется особая память, представленная регистрами процессора, которая обычно представляет собой небольшое хранилище информации, обеспечивающее крайне высокую скорость обмена данными. Регистры — это самая быстрая память, с которой может работать процессор, которая расположена максимально близко к остальным его механизмам и имеет небольшой объем. Иногда регистры называют кэшем нулевого уровня (L0 Cache, L — это сокращение от Layer).
У процессоров, кроме того, имеется доступ к еще нескольким уровням кэш-памяти. Это — до четырех уровней кэша, которые, соответственно, называются кэшами первого, второго, третьего, и четвертого уровня (L0 — L4 Cache). То, к какому именно уровню относятся регистры процессора, в частности, будет ли это кэш нулевого или первого уровня, определяется архитектурой процессора и материнской платы. Кроме того, от архитектуры системы зависит то, где именно — на процессоре, или на материнской плате, физически расположена кэш-память разных уровней.
Структура памяти в некоторых новейших CPU
Жесткие диски (HDD, Hard Disk Drive), применяемые для постоянного хранения данных — это, в сравнении с оперативной памятью, предназначенной для кратковременного хранения информации, устройства довольно медленные. Однако надо отметить, что скорость постоянных хранилищ информации увеличивается благодаря распространению твердотельных накопителей (SSD, Solid State Drive).
В системах долговременного хранения информации кэш диска (его еще называют буфером диска или кэширующим буфером) — это встроенная в жесткий диск память, которая играет роль буфера между процессором и физическим жестким диском.
Кэш жесткого диска
Дисковые кэши работают, исходя из предположения, что когда на диск что-то пишут, или с него что-то читают, есть вероятность того, что в ближайшем будущем к этим данным будут обращаться снова.
Разница между временным хранением данных в оперативной памяти и постоянным хранением на жестком диске проявляется в скорости работы с информацией, в стоимости носителей и в близости их к процессору.
Время отклика оперативной памяти составляет десятки наносекунд, в то время как жесткому диску нужны десятки миллисекунд. Разница в быстродействии дисков и памяти составляет шесть порядков!
Одна миллисекунда равна миллиону наносекунд
Consistent hashing Согласованное хеширование (англ. consistent hashing) — особый вид хеширования, отличающийся тем, что когда хеш-таблица перестраивается, только 
ключей в среднем должны быть переназначены, где 
— число ключей и 
число слотов (slots, buckets). В противоположность этому, в большинстве традиционных хеш-таблиц, изменение количества слотов вызывает переназначение почти всех ключей.
Согласованное хеширование достигает тех же целей, что и рандеву-хеширование (англ. rendezvous hashing). Обе методики используют разные алгоритмы, и были разработаны независимо и одновременно.
если данные меняются? используется инвалидация
Инвалидация кеша - это процесс удаления всех кешированных объектов, связанных с изменениями в состоянии вашей модели. Наиболее распространенным типом инвалидации является прямое удаление объектов. Но если состояние первоначального источника распространилось на несколько кешированных объектов, то содержать их в синхронизрованном состоянии может быть сложно.
Возможны два механизма, чтобы помочь решить эту проблему:
Кэширование (или кэш) – это некий промежуточный буфер, в котором хранятся данные. Благодаря кэшированию страница сайта не воссоздается заново для каждого пользователя. Кэширование позволяет осуществлять работу с большим количеством данных в максимально сжатые сроки и при ограниченных ресурсах (серверных и пользовательских).
Необходимо понимать, что работу с данными можно производить как на стороне клиента, так и на сервере. Притом, серверная обработка данных централизована и имеет ряд несомненных преимуществ (особенно для службы поддержки).
Существует несколько видов кэширования, предлагаем рассмотреть каждый вид, его особенности и рекомендации по применению:
Представляет собой составление для браузера команды использовать имеющуюся кэшированную копию. Работа такого кэширования основана на том, что при повторном посещении, браузеру отдается заголовок 304 Not Modified, а сама страница или картинка загружаются из локального пользовательского кэша. Получается, что вы экономите на трафике между браузером посетителя и хостингом сайта. Соответственно, страница вашего сайта начинает загружаться быстрее.
Браузерное кэширование как нельзя лучше подходит для сайтов, содержащих большое количество изображений: картинка не скачивается каждый раз при открытии сайта, а просто загружается через кэш браузера.
Это первый уровень кэширования, который состоит в отдаче заголовка «expired» и заголовка «304 Not Modified». Наиболее эффективным считается кэширование на 2 недели.
Однако в данном случае есть важный нюанс: если изображение на сайте меняется, то браузер узнает об этом не сразу, а только если выждать expiry или сбросить кэш в самом браузере. Это не очень эффективно, если файл постоянно изменяется и необходимо постоянно отдавать его актуальную версию.
Специальные заголовки вида strict-security. Позволяет браузеру всегда обращаться по https к выбранному домену. Сохраняет это состояние довольно жестко и, в случае отмены этого вида кэша, браузер еще довольно долго будет пытаться загрузить страницу по https, при этом игнорируя текущие заголовки.
Так называемый, stamp центра сертификации.
Данный вид кэширования считается обязательным для применения, если вы не хотите, чтобы пользователи вашего сайта ждали, когда центр сертификации (а это некий сервер, который отвечает за достоверность вашего сертификата) обработает запрос от браузера пользователя и подтвердит, что ваш сайт действительно подтвержден им.
Когда страница уже сгенерирована, нужно постоянно отслеживать ее актуальность. Для этого вы должны использовать серверный кэш с отслеживанием времени изменения отдельных частей страницы (если страница строится из множества динамически генерируемых блоков). При таком подходе в каждом ответе от сервера установлены специальные заголовки, обозначающие время изменения страницы, которые затем отправляются браузером пользователя при повторном обращении к странице сайта. Сервер при получении таких заголовков можем проанализировать текущее состояние страницы (возможно, даже отрисовать ее), но вместо содержимого страницы отдать заголовок «304 Not Modified», что для пользовательского браузера будет означать, что можно показать страницу из своего (браузера пользователя) кэша.
Конечно, можно отправлять соответствующие заголовки без использования серверного отслеживания кэша, но в таком случае большинство пользователей получат обновление контента страницы довольно поздно. При таком подходе браузер иногда опрашивает сервер для получения обновлений, но периодичность и правила для каждого браузера настраиваются его разработчиком, поэтому надеяться на то, что ваши пользователи получат обновления вовремя, не приходится.
Как правило, кэш подразделяется по типу пользователей:
— для авторизованных;
— для неавторизованных.
Данное разделение обусловлено уникальностью контента, для каждого авторизованного пользователя и общностью контента для гостевых пользователей. В большинстве сайтов не авторизованный пользователь не может изменять содержимое сайта, а значит и влиять на его содержимое.
Браузерный кэш позволяет экономить трафик и время, затрачиваемое на загрузку страниц. Но для достижения эффекта экономии, пользователь должен хотя бы один раз посетить нашу страницу, а это означает, что нагрузка на серверные ресурсы уменьшится, но не значительно.
Под серверным кэшированием понимаются все виды кэширования, при котором данные хранятся на серверной стороне. Эти данные не доступны клиентским браузерам. Кэш создается и хранится по принципу «один ко многим» (многие, в данном случае, — это клиентские устройства).
Наиболее эффективный кэш. Чем он интересен? Самое большое его достоинство в том, что отдача страницы происходит практически в момент обращения, как следствие – это возможность обработки миллионов запросов даже на самом слабом сервере со скоростью работы памяти и с незначительным задействованием процессора.
Пожалуй, любой когда-либо мечтал о сайте, работающем со скоростью «ping» или быстрее.
Но и у этого типа кэша есть свои минусы: например, невозможность кэшировать страницы для авторизованного пользователя, либо пользователя, содержимое страницы которого зависит от текущих переменных пользователя.
Используйте этот кэш, если серверу известны все статичные состояния внешних данных, такие как: uri, get (без дополнительных параметров), пользователь не авторизован — то есть, фактически, это идеальное состояние страницы для гостевых пользователей. Учитывайте тот факт, что при таком кэшировании архитектура сайта или приложения всегда должна однотипно обрабатывать входящие запросы и отдавать однотипные ответы. Такое состояние есть в любом приложении или сайте, его нужно лишь отследить и применить к нему кэш.
Кэширование страниц целиком, чаще всего, применяют в каких-то экстренных случаях, при этом кэш страниц сохраняется на заранее указанное время (от 2 минут), в течение которого ответы от сервера однотипны (не позволяйте браузеру кэшировать это).
Различают как чистую компиляцию кода, так и его оптимизацию во время компилирования (подмена скриптов). Наиболее яркие примеры:
— APC;
— XCache;
— Компиляция с подменой скриптов HipHopVirtualMachine.
И тот и другой вид кэширования могут использоваться в проекте, но у каждого есть собственные нюансы, которые необходимо учитывать при написании кода.
Лучше всего подходит при стандартизации запросов, получении данных из общих ресурсов, наличии внутренних переменных, к которым php-ресурсы обращаются несколько раз при генерации страницы.
Такое кэширование применяйте для хранения сериализированных данных. Например: конфигурационного файла, состояния таблиц, списков файловой системы.
Это довольно известная и наиболее освещенная тема. Тем не менее, хотелось бы рассмотреть специфику работы с timestamp и то, как можно избежать постоянного сброса query cache.
Наверняка, вы регулярно сталкивались с ситуацией, когда необходимо отдать новые материалы, дата публикации которых уже разрешена текущим timestamp? Проще говоря,
WHERE show_ts<=UNIX_TIMESTAMP()
Если использовать постоянно меняющийся timestamp в таких запросах, то sql кэш будет не только бесполезен, но даже вреден, так как будет копиться количество кэшированных запросов, данные которых устарели в момент создания кэша.
Мы предлагаем следующий выход из ситуации:
Как правило, любой материал публикуется в определенные моменты времени. К примеру, 00:00. Все что нужно сделать — создать запрос, который будет оценивать таблицу по максимальной дате, при этом, меньшей текущей.
Что-то вроде:
SELECT SQL_NO_CACHE MAX(show_ts) … WHERE show_ts<=UNIX_TIMESTAMP();
Да, этот запрос кэшироваться не будет, но будут кэшироваться все запросы к этой таблице, если их количество больше одного. Эта простая операция существенно улучшит жизнь sql-кэширования.
Кэшировать эти запросы имеет смысл, если чтений из таблицы немного больше чем записи.
Существует правило: обновлений данных должно быть значительно меньше, чем чтения для их отдачи.
То есть не имеет смысл агрегировать то, что изменится в тот же момент, при этом важна актуальность агрегированных данных.
Что выбирать для агрегирования? Обычно это какая-то статистическая информация о числе записей, дате последнего обновления, авторе последнего обновления и тому подобное.
Теперь, когда мы обсудили роль кэширования в базовых механизмах компьютерных систем, рассмотрим пример, иллюстрирующий применение концепций кэширования при взаимодействии клиента, представленного веб-браузером, и сервера, который, реагируя на запросы клиента, отправляет ему некие данные. В самом начале у нас имеется простой веб-сервер, который, отвечая на запрос клиента, считывает данные с жесткого диска. При этом представим, что между клиентом и сервером нет никаких особых систем кэширования. Вот как это выглядит.
Простой веб-сервер
При работе вышеописанной системы, когда клиент обращается напрямую к серверу, а тот, самостоятельно обрабатывая запрос, читает данные с жесткого диска и отправляет клиенту, без кэша все-таки не обходится, так как при работе с диском будет задействован его буфер.
При первом запросе жесткий диск проверит кэш, в котором, в данном случае, ничего не будет, что приведет к так называемому «промаху кэша». Затем данные считаются с самого диска и попадут в его кэш, что соответствует предположению, касающемуся того, что эти данные могут понадобиться снова.
При последующих запросах, направленных на получение тех же данных, поиск в кэше окажется успешным, это — так называемое «попадание кэша». Данные в ответ на запрос будут поступать из дискового буфера до тех пор, пока они не будут перезаписаны, что, при повторном обращении к тем же данным, приведет к промаху кэша.
Усложним наш пример, добавим сюда базу данных. Запросы к базам данных могут быть медленными и требовать серьезных системных ресурсов, так как серверу баз данных, для формирования ответа, нужно выполнять некие вычисления. Если запросы повторяются, кэширование их средствами базы данных поможет уменьшить время ее отклика. Кроме того, кэширование полезно в ситуациях, когда несколько компьютеров работают с базой данных, выполняя одинаковые запросы.
Простой веб-сервер с базой данных
Большинство серверов баз данных по умолчанию настроены с учетом оптимальных параметров кэширования. Однако, существует множество настроек, которые могут быть модифицированы для того, чтобы подсистема баз данных лучше соответствовала особенностям конкретного приложения.
Продолжим развивать наш пример. Теперь веб-сервер, раньше рассматриваемый как единая сущность, разбит на две части. Одна из них, собственно веб-сервер, теперь занимается взаимодействием с клиентами и с серверным приложением, которое уже работает с системами хранения данных. Веб-сервер можно настроить так, чтобы он кэшировал ответы, в результате ему не придется постоянно отправлять серверному приложению похожие запросы. Похожим образом, основное приложение может кэшировать некоторые части собственных ответов на ресурсоемкие запросы к базе данных или на часто встречающиеся запросы файлов.
Кэш ответов и кэш приложения
Ответы веб-сервера кэшируются в оперативной памяти. Кэш приложения может храниться либо локально, в памяти, либо на специальном кэширующем сервере, который использует базу данных, вроде Redis, которая хранит данные в оперативной памяти.
браузеры — быстрее открывают страницу (повторно, «Назад») поисковики — быстрее индексируют прокси — лучше работают А нагрузка — снижается… Защита от умника с кнопкой F5
Браузеры/прокси могут сохранять HTTP-ответы Есть статус ответа HTTP 304 Not Modified Есть заголовки для управления кэшированием Причем частично в довольно диких комбинациях Куча костылей для проксей
однако иногда нужно отключить кеш. страницы с критичным изменениями, наприимер корзина, при разработке, при получании часто изменяемых данных, например уведомлений
Минимум 5 уровней кеширования: данные (в RAM), рендер модуля (HTML), рендер страницы(HTML), статика на клиенте(JS/CSS), объектные коды скриптов (Opcache) и все их нужно отключить на время разработки.
Сейчас поговорим об оптимизации производительности серверного приложения за счет мемоизации. Это — разновидность кэширования, применяемая для оптимизации работы с ресурсоемкими функциями. Данная техника позволяет выполнять полный цикл вычислений для определенного набора входных данных лишь один раз, а при следующих обращениях к функции с теми же входными данными сразу выдавать найденный ранее результат. Мемоизация реализуется посредством так называемых «таблиц поиска» (lookup table), хранящих ключи и значения. Ключи соответствуют входным данным функции, значения — результатам, которые возвращает функция при передаче ей этих входных данных.
Мемоизация функции с помощью таблицы поиска
Мемоизация — это обычный прием, используемый для повышения производительности программ. Однако он может быть не особенно полезным при работе с ресурсоемкими функциями, которые вызываются редко, или с функциями, которые, и без мемоизации, работают достаточно быстро.
Теперь перейдем на сторону клиента и поговорим о кэшировании в браузерах. В каждом браузере имеется реализация HTTP-кэша (его еще называют веб-кэшем), который предназначен для временного хранения материалов, полученных из интернета, таких, как HTML-страницы, JavaScript-файлы и изображения.
Этот кэш используется, когда в ответе сервера содержатся правильно настроенные HTTP-заголовки, указывающие браузеру на то, когда и на какое время он может кэшировать ответ сервера.
Перед нами весьма полезная технология, которая дает следующие преимущества всем участникам обмена данными:
Кэширование в браузере
В компьютерных сетях прокси-серверы могут быть представлены специальным аппаратным обеспечением или соответствующими приложениями. Они играют роль посредников между клиентами и серверами, хранящими данные, которые этим клиентам требуются. Кэширование — это одна из задач, которую они решают. Рассмотрим различные виды прокси-серверов.
Шлюз (gateway) — это прокси-сервер, который перенаправляет входящие запросы или исходящие ответы, не модифицируя их. Такие прокси-серверы еще называют туннелирующими прокси (tunneling proxy), веб-прокси (web proxy), прокси (proxy), или прокси уровня приложения (application level proxy). Эти прокси-серверы обычно совместно используются, например, всеми клиентами, находящимися за одним и тем же файрволом, что делает их хорошо подходящими для кэширования запросов.
Прямой прокси-сервер (forward proxy, часто такие серверы называют просто proxy server) обычно устанавливается на стороне клиента. Веб-браузер, который настроен на использование прямого прокси-сервера, будет отправлять исходящие запросы этому серверу. Затем эти запросы будут перенаправлены на целевой сервер, расположенный в интернете. Одно из преимуществ прямых прокси заключаются в том, что они защищают данные клиента (однако, если говорить об обеспечении анонимности в интернете, безопаснее будет пользоваться VPN).
Веб-ускоритель (web accelerator) — это прокси-сервер, который уменьшает время доступа к сайту. Он делает это, заранее запрашивая у сервера документы, которые, вероятнее всего, понадобятся клиентам в ближайшем будущем. Подобные серверы, кроме того, могут сжимать документы, ускорять выполнение операций шифрования, уменьшать качество и размер изображений, и так далее.
Обратный прокси-сервер (reverse proxy) — это обычно сервер, расположенный там же, где и веб-сервер, с которым он взаимодействует. Обратные прокси-серверы предназначены для предотвращения прямого доступа к серверам, расположенным в частных сетях. Обратные прокси используются для балансировки нагрузки между несколькими внутренними серверами, предоставляют возможности SSL-аутентификации или кэширования запросов. Такие прокси выполняют кэширование на стороне сервера, они помогают основным серверам в обработке большого количества запросов.
Обратные прокси-серверы расположены близко к серверам. Существует и технология, при использовании которой кэширующие серверы располагаются как можно ближе к потребителям данных. Это — так называемое пограничное кэширование (edge caching), представленное сетями доставки контента (CDN, Content Delivery Network). Например, если вы посещаете популярный веб-сайт и загружаете какие-нибудь статические данные, они попадают в кэш. Каждый следующий пользователь, запросивший те же данные, получит их, до истечения срока их кэширования, с кэширующего сервера. Эти серверы, определяя актуальность информации, ориентируются на серверы, хранящие исходные данные.
Прокси-серверы в инфраструктуре обмена данными между клиентом и сервером
Иерархический MVC
Блочная структура естественна Удобно кэшировать!
Юзают авторы поделия под названием Kohana Framework
Однако они о кэшировании НЕ ЗНАЮТ! и поэтому его там правильного нет
Fail № 1 «Положил и точно заберу» Например, сессии в memcached
Fail № 2 Кэширование авторизованных страниц Или одного и того же списка с выбранным элементом (итог — комбинаторный взрыв)
Fail № 3 Аппарат искусственного дыхания Будет очень грустно его отключать (сбрасывать кэш)
Fail № 4 Cache hit под 100 %, а все тормозит! Кэшировали яро, но не то, что надо
Потратив время на то, чтобы ваш сайт имел правильную политику кэширования, вы можете оказать значительное влияние на сайт. Кэширование позволяет сократить расходы, связанные с одновременным обслуживанием одного и того же контента.
Сервер также сможет обрабатывать большее количество трафика с помощью того же аппаратного обеспечения. Возможно, самое главное – кэширование может улучшить пользовательский опыт, благодаря чему посетители будут возвращаться на сайт. Конечно, эффективное кэширование – не волшебная палочка, но это может значительно повысить производительность.
Представленные результаты и исследования подтверждают, что применение искусственного интеллекта в области виды кеширования имеет потенциал для революции в различных связанных с данной темой сферах. Надеюсь, что теперь ты понял что такое виды кеширования, кеширование, кеш и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Высоконагруженные проекты.Паралельные вычисления. Суперкомпьютеры. Распределенные системы
Комментарии
Оставить комментарий
Высоконагруженные проекты.Паралельные вычисления. Суперкомпьютеры. Распределенные системы
Термины: Высоконагруженные проекты.Паралельные вычисления. Суперкомпьютеры. Распределенные системы