«Московские новости» публикуют топ-13 иностранных слов, в которых надо писать «е» вместо «э», и одно русское слово, где все как раз наоборот.
1. Риелтор. Это слово — одно из самых богатых на варианты написания. Пишут и «риэлтор», и «риэлтер», и «риелтор». На самом же деле пишется в нем «е», как в словах «абитуриент» и «диета», но произносится «э». Это тот случай, когда написание надо просто запомнить.
2. Бренд и тренд. По правилам после согласной почти всегда пишется «е», даже если слышится «э». Исключений немного: мэр, пэр, сэр, мэтр, рэп, рэкет, пленэр. Правда, с некоторыми словами язык определяется не сразу. Но даже если возможно разное написание, вариант с «е» уверенно берет свое: в современных словарях есть и тренд, и бренд — именно так, через «е».
3. Кеш. Да-да, как ни странно, это слово, обозначающее наличность, мы можем найти в орфографическом словаре В.В. Лопатина именно в таком виде — похоже на орешки кешью. А вот компьютерный термин («пользователь удалил запись, но кэш «Яндекса» помнит все») пишется через «э»: по крайней мере такой вариант есть в словаре трудностей русского языка.
4. Хеллоуин. В орфографическом словаре В.В. Лопатина название этого праздника есть, и зафиксирована в нем именно буква «е», хотя через «э» это слово пишут очень часто. Но тут срабатывает общее правило: после согласного «е», а не «э».
В рубрике «Вспомнить все» объясняем правила русского языка так, чтобы стало понятно
5. Кашне и портмоне. В конце этих слов явно слышится «э», но пишутся они через «е» — это надо запомнить. А вот до революции все было по-другому: писали кашнэ, портмонэ. Это делалось для того, чтобы согласная «н» в этих словах не произносилась мягко, как в местоимении «мне».
6. Коттедж. Подчиняется общему правилу, пишется исключительно через «е».
7. Стейк и брейк. Тут тоже велико искушение написать «брэйк», но не забывайте о правиле. К исключениям типа «мэра» и «пэра» новых слов пока никто не добавлял.
8. Мейл/имейл. Казалось бы, уж мейл-то точно должен писаться через «э»! Но и тут правило непоколебимо. Оба слова есть в орфографическом словаре.
9. Фейсбук. Вокруг Фейсбука было много споров: лингвисты и пользователи обсуждали и ударение (ФейсбУк или ФЕйсбук), и то, нужна ли прописная буква, и выбор между «е» или «э». Слово в итоге подчинилось общему правилу: после согласной «ф» в нем пишется «е», хотя слышится «э». В словарях написание Фейсбука еще не зафиксировано, хотя он сам указал пользователям на свой выбор. Взгляните на то, как написано слово в левом верхнем углу экрана.
10. Карате. Здесь ситуация как с кашне и портмоне. Раньше писалось «э», потом «е».
Владимир Пахомов, главный редактор Грамоты.ру:
— Когда в 2009 году возник скандал со словарями и журналисты стали писать о том, что в них появились «йогУрт» и «черное кофе», под горячую руку попало и карате. «Теперь можно писать «карате»!» — писали журналисты как о какой-то новой норме. А на самом деле «э» в этом слове сменилось на «е» еще в конце 1990-х и официально закрепилось в таком виде в словарях.
Одно русское слово. Может возникнуть вопрос: почему же через «э» пишется слово «зэк» (а именно такой, единственный, вариант дает новый орфографический словарь). По правилам через «э» пишутся названия букв: бэ, вэ, гэ, дэ и т. д. Это же правило распространяется и на аббревиатуры, которые состоят из названий букв. Слово «зэк», как известно, представляет собой именно аббревиатуру з/к, что означает «заключенный контингент». Аналогичные примеры — кавээнщик, кагэбэшник, эсэмэска.
Интересный факт
Букву «э» очень любил поэт Игорь Северянин. Он считал, что она придает словам изысканность и аристократичность. Есть даже стихотворение, которое называется «Березовое шалэ». Свои стихи Северянин часто наполнял бесчисленными «э»:
Элегантная коляска в электрическом биеньи
Эластично шелестела по прибрежному песку…
Я в электрической коляске на эллиптических рессорах…
Даже обычную российскую избу Северянин предлагал «облагородить» с помощью буквы «э». Если написать «эзба», считал он, сразу возникнет образ не крестьянского дома, а того самого «березового шалэ».
кэш или кеш? — Говорим и пишем правильно — ЖЖ
?
LiveJournal
Find more
- Communities
- RSS Reader
- Shop
Help
Login
- Login
Все, что нужно знать о кэшировании / Хабр
Доброго времени суток.
Представляю вашему вниманию перевод статьи «Everything you need to know about Caching — System Design» автора Animesh Gaitonde.
Введение
Вы замечали, что при просмотре веб-страницы при плохом соединении с Интернетом текст загружается перед высококачественными изображениями? Однако при повторном посещении той же страницы, она загружается намного быстрее. При посещении нового сайта для его загрузки требуется гораздо больше времени, чем для загрузки часто посещаемых сайтов, таких как Facebook или Amazon. Вы знаете, почему так происходит? Все дело в кэшировании.
Так выглядит моя страница в Instagram при медленном соединении. Как видите, текст отображается, в то время как изображения еще не загрузились.
Очень важно обеспечить лучший опыт использования приложения для удержания и вовлечения пользователей. В современном мире, где царствует дух соревнования, бизнес сильно страдает из-за плохого пользовательского опыта. Представьте, что вы смотрите свой любимый сериал или потоковое видео на веб-сайте, но видео постоянно останавливается для дозагрузки (буферизации). Долго ли вы будете терпеть такое «отношение», и вернетесь ли вы на такой сайт?
Кэширование работает по принципу «локализации ссылок». Кэш представляет собой локальное хранилище данных для ускорения поиска информации и восстановления данных. Основной целью кэша является уменьшение задержки чтения данных и увеличение пропускной способности приложения. Давайте рассмотрим несколько примеров из реальной жизни.
Использование кэша
Предположим, что вы готовите ужин каждый день. Для приготовления еды вам нужны различные ингредиенты, овощи, специи и т.д. Однако ходите ли вы за этим в магазин каждый день? Это может быть довольно обременительным и затратным по времени. Разумеется, первым делом вы заглядываете в шкаф на кухне или холодильник. Это помогает избежать лишнего похода в супермаркет.
Ваш холодильник представляет собой своего рода кэш для овощей. Очевидным преимуществом такого кэша является существенная экономия времени приготовления ужина.
Как работает кэш?
Серверные приложения обычно хранят данные в базе данных. Когда клиент запрашивает данные, приложение отправляет запрос к базе данных, получает оттуда данные и отправляет их клиенту. Сервер базы данных работает в автономном режиме и может находиться на другом компьютере, нежели компьютер, на котором находится сервер приложения.
Чтение данных из базы данных является очень медленным процессом, поскольку необходимо отправить запрос и выполнить операции ввода-вывода для получения данных из файловой системы. Если данные хранятся в кэше, операция чтения будет очень быстрой. Когда клиент повторно запрашивает те же данные, имеет смысл вернуть данные из кэша вместо базы данных.
Например: если твит стал вирусным, все клиенты будут запрашивать данные по одному и тому же твиту. Поскольку Twitter имеет миллионы пользователей, использование кэша позволяет избежать миллионов запросов к базе данных.
Таким образом, кэш снижает нагрузку на базу данных. Если запрашиваемые данные имеются в кэше, запрос к базе данных будет перенаправлен (перехвачен). Можно провести некоторую аналогию с хэш-таблицей, хранящей пары «ключ-значение».
Следующая диаграмма демонстрирует процесс чтения данных из кэша:
Ключевые концепции кэша
Время жизни (Time to Live, TTL)
Это ограничения количества данных, которые можно хранить в кэше. Необходимо удалять записи в кэше, которые больше не нужны серверу приложения.
В случае с Netflix, сервер будет кэшировать наиболее часто просматриваемые или популярные шоу. Не никакой надобности хранить в кэше шоу, которые никто не смотрит.
Например: хранить в кэше сериал «Бумажный дом» рациональней, чем фильм «Индиана Джонс».
Политика удаления
В определенный момент кэш заполняется. Отсюда возникает необходимость удаления старых (неактуальных) данных и их замены новой (востребованной) информацией.
Существует несколько политик очистки кэша, таких как «старые (наименее недавно используемые)» (Least Recently Used, LRU), «редко запрашиваемые (наименее часто используемые)» (Least Frequently Used, LFU), «последние (наиболее недавано используемые)» (Most Recently Used, MRU). Эти политики удаляют данные из кэша по определенному принципу.
Старые
Из кэша удаляются данные, которые давно не запрашивались. Как только кэш заполняется, старые данные удаляются, новые добавляются.
Представим, что Facebook кэширует фото знаменитостей. Анализ запросов подписчиков свидетельствует о востребованности новых фото. Когда кэш заполнится, самое старое фото будет из него удалено.
Редко запрашиваемые
LFU отслеживает частоту или количество запросов данных. Когда размер кэша приблизится к пороговому значению, будут удалены самые редко запрашиваемые данные.
Когда мы вводим текст, телефон начинает предлагать различные варианты окончания слова, один из которых можно выбрать вместо полного набора (автозавершение). Программное обеспечение смартфона кэширует самые часто набираемые слова.
Из этого кэша впоследствии удаляются редко набираемые слова. В приведенном примере, если вы будете использовать слова «feature», «features», «feather» и т.д., через какое-то время телефон перестанет предлагать вам «feat», поскольку оно будет удалено из кэша.
Последние
В этой политике удалению подлежат последние данные, предпочтение отдается более старым данным, хранящемся в кэше. Данная стратегия используется в случае, если шаблон получения данных таков, что пользователь наименее заинтересован в повторном получении последних данных. Рассмотрим пример.
Приложения для знакомств, такие как Tinder, обычно кэшируют всех потенциальных партнеров (возможные совпадения или предпочтения) пользователя. Когда пользователь листает ленту, сдвигая определенный профиль потенциального партнера влево или вправо, приложение больше не должно рекомендовать ему этот профиль. Если такое случится, это приведет к плохому пользовательскому опыту.
В данном случае существует необходимость удаления последних данных. Приложение должно удалять из кэша просмотренные профили.
Типы кэша
Запись через кэш
Как следует из названия, данные записываются сначала в кэш, затем в базу данных. Это обеспечивает согласованность данных в кэше и базе данных. Каждое чтение данных из кэша соответствует самой последней записи.
Недостатком такого подхода является увеличение времени выполнения записи. Он не подходит для высоконагруженных систем с частыми операциями записи данных. Однако он отлично подходит для приложений, часто перечитывающих данные, хранящиеся в БД. Медленная запись компенсируется быстрым чтением и согласованностью.
Запись из кэша
Альтернативой первому подходу служит запись данных в кэш и добавление отметки об изменении данных для их последующего обновления в БД.
С помощью периодических асинхронных операций можно читать обновленные данные в кэше и вносить изменения в соответствующие данные в БД. Данный подход не увеличивает время выполнения операций чтения-записи. Единственным недостатком здесь является задержка в синхронизации между кэшем и БД. Это может привести к тому, что приложения, полагающиеся на БД как на источник истины, будут читать устаревшие данные.
Youtube, например, использует рассматриваемый подход для хранения информации о количестве просмотров определенного видео. Обновление БД для каждого просмотра вирусного видео будет очень затратным. Лучшим решением является запись данных в кэш и последующая синхронизация с БД.
Запись в обход кэша
Несколько серверных приложений не часто перечитывают последние данные. В этом случае используется запись в обход кэша.
В данном подходе БД обновляется без кэша. Это позволяет избежать загрузки в кэш невостребованных данных. Однако если приложение все-таки запросит последние данные, отсутствующие в кэше, это приведет к загрузке таких данных из БД со всеми вытекающими последствиями.
Примеры использования кэша в распределенных системах
Список открытых проектов для работы с кэшем:
- Redis
- Memcached
- VoltDB
- Aerospike DBS
- Apache Ignite
Благодарю за внимание.
01 июня, 2020
Автор: Maksim
Кэш является важной составляющей большого количества различного программного и аппаратного обеспечения. Он позволяет операционной системе или программе быстрее запускаться и вообще работать.
О том, что он из себя представляет — его определение, как работает и, зачем вообще он нужен, и будет данный материал. Рассмотрим на реальном примере, как это все функционирует.
Из прошлой публикации вы могли узнать, что такое куки файлы. Сегодня мы поговорим о других, не менее важных файлах для компьютеров, ноутбуков, смартфонов или планшетов — кэше. Вы узнаете определение этого термина, зачем он нужен, и как вообще работает.
Что такое кэш — Cache
Кэш (cache) — это временные копии файлов какого-либо программного обеспечения, которые хранятся в определенном месте, чтобы к ним был быстрый доступ. Совокупность временных файлов и место их хранения называется кэшем. Нужен он в первую очередь для быстро доступа к файлам, которые в нем хранятся.
Кэширование — это процесс записи копий файлов в кеш. Происходит в процессе использования операционной системы и отдельных программ, они делают его автоматически, чтобы загружать свои же данные потом из него.
Используется большим количеством различного программного обеспечения. В одной из публикаций я уже затрагивал данную тему, там мы осуждали кэш браузера, рекомендую ее к прочтению.
Как работает Cache:
Большинство программ хранят свои файлы в заархивированном виде или вообще на сервере в интернете. И, когда вы к ним обращаетесь, чтобы достать такие файлы нужно, какое-то время. Чтобы каждый раз не разархивировать их или не скачивать их из интернета заново — они попадают кэш. И, в следующий раз, когда вы к ним обратитесь — данные будут загружаться быстрее.
Большинство кэшированных файлов записываются в оперативную память, т.к. она обладает очень высокой скоростью чтения и записи, все данные из нее считываются очень быстро.
Существует две реализации кэширования данных — аппаратный и программный.
Аппаратная — когда запись временных файлов для быстрого к ним доступа реализована на самом устройстве в виде выделенной на нем памяти. К примеру, на центральном процессоре, аппаратное есть три вида cache памяти, куда попадают данные, это L1, L2 и L3.
Т.е. уже на самом устройстве есть выделенные ячейки памяти, куда он записывает самые важные файлы, чтобы получить к ним быстрый доступ, не обращаясь к другим устройствам в системе.
Программная — такой тип реализации означает выделенную память уже в операционной системе, обычно это простая папка. В зависимости от программы — местоположение кэша может меняться. Браузеры к примеру, хранят его в своих папках в Document and Settings.
Подытожим — Кэш нужен для:
1. Быстрого доступа к файлам
2. Быстрой загрузки программ
3. Экономии трафика
4. Экономии ресурсов системы и в следствии более высокой ее производительности
Кэш память, что это такое
Кэш память — это встроенная в устройство память, выделенная для записи в нее временных файлов для быстрого к ним доступа. Устанавливается на процессоры и другие устройства, позволяет значительно увеличить быстродействие и доступ к необходимым файлам. Часто можно встретить на ССД — до 4 Гб памяти и жестких дисках — до 256 Мб.
При аппаратной реализации временные данные очищаются обычно сами и участия пользователя не требуется, многие даже не подозревают, что такой вид кеша вообще существует.
Как очищать кэш
Очистка таких данных в операционной системе обычно проходит в автоматическом режиме и не требует участия от пользователя лишь за редкими исключениями. Как очистить кэш браузера я уже писал — просто нажмите разом клавиши «CTRL +F5» на активной странице в браузере.
В другом же ПО процесс удаления делается через меню настроек, в самой программе нужно найти соответствующий пункт меню и очистить данные. Благо в ОС Windows в большинстве своем такая очистка может понадобиться лишь для браузеров.
В IOS на iPhone этот процесс полностью автоматизирован, а вот владельцам Android приходится часто делать эту процедуру вручную. Но, с каждой новой версий и там все становится куда более понятнее и автоматизированнее.
Зачем очищать кэш?
В редких случаях функция кэширования может неправильно работать и загружаться, будет устаревший контент вместо нового, часто такое происходит именно в браузерах. Поэтому его приходится чистить. К примеру, если на каком-либо сайте данные были обновлены, к примеру, загружены новые картинки, изменены стили — браузер может загрузить старую версию.
Чтобы очистить его и загрузить новую страницу достаточно нажать на открытой активной странице «CTRL + F5» и она обновится с новыми данными.
В заключение
Это основные моменты, что нужно знать о кеше. Надеюсь информация оказалась вам полезной и интересной. Приятного вам серфинга в сети и быстрого интернета.
Написано не мало хороших статей на тему «Что, как и где кешировать». Так почему же ещё раз мусолить эту тему? А потому что тема достаточно важная, а многие, пока не столкнуться с конкретными проблемами, не считают нужным с ней разбираться. Так что аудитория, на которую я рассчитываю, это те, кто к моменту выхода уже существующих статей были в них не заинтересованы, но сейчас интерес есть, и они не пройдут мимо.
Я постараюсь кратко осветить основные моменты организации кеширования, после чего рассмотрю новшества .Net Framework 4.0, которые должны упростить жизнь разработчиков (речь пойдёт о In-memory кеше вне ASP.NET инфраструктуры).
Вступление
Часто, когда речь заходит о производительности, довольно сложно обойтись без применения техники кеширования. Но прежде, чем мы сможем её эффективно применить, нам надо ответить на следующие вопросы:
- Что кешировать: какие именно данные должны сохраняться в кеше;
- Как кешировать: какой максимальный объём мы можем выделить для работы кеша; будет ли установлено максимально допустимое время, в течении которого элемент не будет считаться устаревшим; будет ли актуальность наших элементов в кеше зависеть от каких-то внешних факторов или будут зависимости между самими элементами внутри кеша; будет ли важен порядок, в котором мы будем удалять элементы из кеша при достижении лимита памяти; и так далее…
- Где кешировать: что будет выступать в роли кеша – в устройствах, это может быть аппаратный кеш, в программах, как правило мы прибегаем к готовой или самописной реализации кеша, которая способна удовлетворить требованиям в вопросе «как»;
Интересно то, что ответы необходимо давать именно в том порядке, как эти вопросы перечислены. Ибо сложно сказать «где кешировать», не понимая, «что и как» мы кешируем. Ещё, крайне желательно позаботиться о кешировании на ранних этапах проектирования системы. Так как вопреки бытующему мнению, что «Кеш всегда можно добавить в последний момент», это зачастую не так. Не думая о кешировании на начальном этапе, потом его добавление и тестирование может быть крайне затруднительным. Давайте попробуем найти ответы на вопросы, заданные выше, но сразу хочу уточнить, что большинство размышлений ниже будут приведены касательно кеша общего назначения внутри .Net приложения хранимого в оперативной памяти, т.е. это не кеш процессора и не кеш браузера. Кроме того, в рамках одной статьи, будет крайне сложно подробно и доходчиво изложить всю возможную теорию кеширования, поэтому я приведу базовые рекомендации и советы, которые надеюсь помогут избежать распространённых ошибок.
Что? Как? Где?
Когда мы решаем, что мы будем кешировать, нужно понимать, что кеш не бесплатный и будет полезен далеко не для всех типов данных. Независимо от выбранной стратегии кеширования и реализации кеша, у нас так или иначе будут проявляться проблемы устаревания данных и занимаемого ими объёма памяти. А в виду того, что кеширование добавляет сложность во время создания /тестирования/сопровождения нашего приложения, то однозначно не нужно кешировать всё подряд. Нужно взвешенно подходить к выбору тех мест, где добавление кеша кроме проблем принесёт ещё и выгоду.
Не стоит кешировать данные, которые полезны только в режиме реального времени. Например, котировки валют в трейдерской системе, устаревшие на 30 секунд, могут весомо повлиять на правильность принимаемых решений. Но если у нас в системе на домашней странице есть сводная статистика по продажам компании за последнюю неделю, то эти данные отлично подойдут для кеширования.
Также нет смысла кешировать то, что можно и так быстро получить из источника данных или высчитать на лету. Но если источник данных находится далеко и очень медленный, а специфика данных позволяет их использовать с какой-то задержкой, то это хорошие кандидаты для кеширования.
В качестве другого примера, давайте рассмотрим данные, которые рассчитываются на лету, требуют много процессорного времени, но полученный результат достаточно большой по объёму. При попытке кеширования этих данных, мы очень быстро можем заполнить всю доступную память, поместив в неё всего лишь несколько результатов. В этих условиях будет сложно добиться эффективной работы кеша, т.к. велика вероятность, что буквально несколько новых элементов будут приводить к затиранию только что рассчитанных значений и процент успешных попаданий (нахождение нужного элемента в кеше) будет крайне низкий. В этом случае нужно скорее задумываться над ускорением алгоритма расчёта, нежели о кешировании результата. Выбирая правильных кандидатов для сохранения в кеш, всегда думайте об эффективности кеша. Т.е. мы должны стремиться к тому, чтобы выбранные нами данные, будучи помещёнными в кеш, извлекались из него многократно до того, как они будут из него вытолкнуты более новыми данными или станут устаревшими.
Думая о том, как правильно хранить наши данные в кеше, нам следует обратить внимание на следующие моменты:
- Своевременное устаревание данных
- Правильная очерёдность удаления элементов при достижении максимально доступного объёма памяти
- Когерентность данных (если кеш распределённый, то один и тот же объект может отличаться в различных экземплярах кеша и тем самым приводить к негативным последствиям)
Некоторые проблемы, связанные с вопросом «как хранить» могут быть на столько сложными, что для их решения создаются отдельные проекты и выделяются специалисты с соответствующим опытом. Надеюсь, что это не относится к вашему проекту, ибо, как я уже сказал, данная статья не будет затрагивать глубины глубин, связанные с вопросами кеширования.
Итак, получив ответы на вопросы «Что» и «Как», может оказаться, что нашим ответом на вопрос где будет Dictionary<T,T> созданный в нашем приложении. Если так, то нам очень повезло. Но, как правило, всё чуточку сложнее и нам всё-таки придётся писать полноценную реализацию кеша либо выбирать что-то из уже готовых решений.
Примечание: нет единого мнения касательно того, будет ли реализация на основе Dictionary считаться кешем или нет. Лично я предпочитаю считать это частным случаем, который обособленно «стоит в сторонке». При этом мне даже встречался термин описывающий такой кеш как «статический», т.е. кеш в котором данные не удаляются и считаются бесконечно актуальными.
Рукописный кеш
Я не стану рассказывать, как написать свой кеш. Я, наоборот, постараюсь уберечь вас от ложного впечатления, что это сделать легко и просто. За исключением случая, когда Dictionary-like реализация отлично покрывает наши потребности, написание полноценного кеша является достаточно сложной задачей.
Первая сложность, которая приходит в голову – это работа в многопоточном окружении. Ведь если мы используем кеш, то наверняка система не маленькая и работать в одном потоке будет крайне неэффективно. Т.е. все операции записи/чтения/инвалидации данных должны быть потоко-безопасны. Без обширного опыта работы с потоками, нам гарантированы взаимоблокировки или медленная работа из-за не оптимально выбранного подхода синхронизации потоков.
Если подумать о том, как происходит устаревание данных, то в голову может прийти ряд далеко не самых простых сценариев, которые должен поддерживать наш кеш. Взяв декартовое произведение всех возможных вариантов, мы получим то множество состояний, в которых сможет оказаться наша система. Это станет достаточным основанием, чтобы сделать задачу отладки и тестирования самописного кеша просто неподъёмной.
Многие примеры, реализующие кеширование, которые можно найти в интернете, используют механизм слабых ссылок (Weak references). Может появиться неудержимое желание применить их в своей реализации. Но без достаточного опыта в соответствующей области, мы не слабо увеличиваем шансы получить код, который мало того, что большинство команды не будет понимать, так он ещё навряд ли заработает после первых 5 раз переписывания.
Я думаю, что мог бы ещё долго продолжать этот список, но надеюсь, что даже уже перечисленных причин достаточно, чтобы у вас пропало желание проверять себя на прочность и усидчивость. Если же нет, то я могу лишь пожелать «Силы, ума и терпения (С)».
Теперь, поняв, что свой кеш это далеко не так просто, я предлагаю перейти к завершающей части статьи, которая расскажет, что уже есть готовое в .NET Framework для упрощения нашей жизни.
Жизнь до появления .Net Framework 4.0
Кеширование всегда было неотъемлемой частью ASP.NET веб приложений и .Net Framework предлагал отличные инструменты для ASP.NET приложений. Поэтому, исторически сложилось так, что все классы для работы с кешом располагались в сборке System.Web. Когда же кеш требовался вне веба (например Windows сервис), то многие разработчики жертвовали красотой своих решений и добавляли ссылку на сборку System.Web. Это позволяло воспользоваться преимуществами кеша, но тянуло за собой огромное количество ненужного кода. Данная проблема оставалась нерешённой достаточно долго, но к счастью, в .NET Framework 4.0 к ней всё-таки вернулись. В итоге мы получили пространство имён System.Runtime.Caching, в котором среди прочего, есть абстрактный класс ObjectCache и его единственная реализация — MemoryCache. Именно с ними я бы и хотел вас познакомить.
ObjectCache
ObjectCache — абстрактный класс, который даёт нам возможность стандартизировать подходы при работе с различными реализациями кеша. Имея одинаковый интерфейс (API) для работы с кешом, нам не придётся детально изучать каждую новую реализацию кеша. Ведь реализации с точки зрения пользователя должны будут выглядеть одинаково и вести себя согласно общеизвестным ожиданиями, выраженными в виде API данного класса. Основные методы, свойства и их назначение приведены ниже.
Свойства:
- DefaultCacheCapabilities – битовыe флаги (enum, с атрибутом Flags), определяющие какие возможности предоставляет конкретная реализация (удаление элемента в определённое время, поддержка регионов, наличие механизма обратного вызова и т.п.)
- Name – имя экземпляра кеша; в случае использования MemoryCache, может быть полезно, если, мы захотим сохранять данные в изолированных участках памяти и будем создавать более одного экземпляра кеша (данная возможность называется «регионы» и в MemoryCache не реализована)
- this – индексер для доступа элементов по ключу
Методы:
- Add(…), AddOrGetExisting(…), Set(…) – добавляют данные в кеш
- Get(…), GetCacheItem(…), GetValues(…) – возвращают данные из кеша
- GetCount() – возвращает текущий размер кеша
- Contains(…) – проверяет существование элемента по ключу
- Remove(…) – удаляет элемент по ключу
Надеюсь теперь, в общих чертах уже понятно, как можно создать свою реализацию кеша. Но есть ещё пару моментов, которые я бы хотел рассмотреть чуть подробней, а именно методы добавления данных в кеш. Предлагаю это сделать, на примере методов в уже существующей реализации кеша – класс MemoryCache.
MemoryCache
Как следует из названия, MemoryCache является реализацией, которая хранит данные в оперативной памяти. На данный момент это единственный класс в .Net Framework, который наследует ObjectCache, но существуют Nuget пакеты, которые предлагают другие реализации (например для хранения данных в Sql сервере можно воспользоваться SqlCache Nuget пакетом). Ниже будут рассмотрены только те методы, работа которых может быть не сразу очевидна. В качестве демонстрации работы методов будут приведены листинги юнит тестов, написанные с использованием xUnit.
Метод AddOrGetExisting(…)
Добавляет элемент, только в случае, если ключ ещё не был использован, иначе игнорирует новое значение и возвращает существующее значение.
Метод Add(…)
Является обвёрткой над AddOrGetExisting(…) и работает практически идентично, с тем лишь различием, что он возвращает True, если элемент успешно добавлен, и False, если ключ уже существует (т.е. добавление значения не происходит).
Метод Set(…)
Добавляет новый или замещает существующий элемент, не производя проверку существующих ключей. Т.е. в отличии от методов Add и AddOrGetExisting, переданное значение в метод Set всегда появится в кеше.
Регионы в MemoryCache
Все методы добавления данных в MemoryCache имеют перегрузки, которые принимают параметр region (пример1, пример2 и пример3). Но при попытке передать в него любое не NULL значение мы получим NotSupportedException. Кто-то может сказать, что это нарушает принцип подстановки Лисков (soLid), но это не так. Ведь прежде чем воспользоваться возможностью регионов, клиентский код должен убедится, что они реализованы в конкретной реализации. Делается это проверкой свойства DefaultCacheCapabilities на наличие соответствующего битового флага (DefaultCacheCapabilities.CacheRegions), а он как раз не задан для MemoryCache.
CacheItemPolicy
Для демонстрации всех методов добавления данных были выбраны наиболее простые версии перегрузок, принимающие ключ, значение и время, до которого значение будет считаться актуальным. Но все они так же имеют версию, которая принимает параметр типа CacheItemPolicy. Именно благодаря этому параметру у нас есть достаточно богатые возможности по управлению временем жизни элемента в кеше, что делает реализацию MemoryCache крайне полезной.
Большинство свойств данного типа выглядят понятно, но на практике мы столкнёмся с множеством неожиданных сюрпризов. Строго говоря, многие из них будут не в самом классе CacheItemPolicy, а в логике методов MemoryCache, которые принимают этот тип. Но так как используются эти типы часто вместе, то предлагаю их рассмотреть тоже вместе.
Свойства AbsoluteExpiration и SlidingExpiration
Из названия понятно за что отвечают эти свойства. Но любопытные могут задаться следующим вопросом: «Как себя поведёт кеш, если одновременно задать значения для обоих свойств»? Кто-то может предположить, что AbsoluteExpiration имеет более высокий приоритет и объект удалится в момент AbsoluteExpiration, даже если его регулярно запрашивать из кеша (чаще чем SlidingExpiration). Кто-то наоборот, предположит, что значение SlidingExpiration позволит объекту пережить AbsoluteExpiration. Но разработчики Микрософта, посчитали, что истинно правильного ответа нет и поступили по-другому – они генерируют ArgumentException на этапе добавления элемента в кеш. Поэтому мы можем выбрать только одну временнУю (зависящую от времени) стратегию инвалидации для каждого элемента.
Второй сюрприз нас ожидает, если мы решим написать тесты на функционал, использующий кеш. Наверняка, для ускорения прогона тестов, мы захотим задать достаточно маленькое значение для SlidingExpiration (менее 1 секунды). В этом случае наши тесты будут вести себя не стабильно и часто будут падать. Это всё по тому, что для оптимизации работы кеша, в момент вычитывания элемента (метод Get и его производные), новое значение Expires будет устанавливаться только, если оно отличается от старого, не менее чем на одну секунду. Я не смог найти подтверждение этому в документации, но убедиться в этом можно декомпилировав класс MemoryCache и изучив метод UpdateSlidingExp(…) внутреннего класса MemoryCacheEntry.
Свойство Priority
Увидев это свойство, я ожидал, что оно может иметь значения «низкий/средний/высокий», чтобы задать порядок удаления элементов из кеша при достижении максимального объёма. Но у него может быть только 2 значения: CacheItemPriority.Default или CacheItemPriority.NotRemovable.
MSDN гласит, что установка значения CacheItemPriority.NotRemovable приведёт к тому, что элемент никогда не будет удалён из кеша. Лично я воспринял этот факт, как то, что, добавив все элементы с таким приоритетом, мы получим Dictionary-like реализацию, но это далеко не так. Элементы всё же будут удалены, если они «протухнут» (наступит AbsoluteExpiration или пройдет SlidingExpiration), но в отличии от режима по умолчанию, они не будут удаляться из памяти, при достижении лимита по объёму занимаемой памяти. Кстати лимит можно задать через свойство CacheMemoryLimit (в байтах) или через свойство PhysicalMemoryLimit (проценты от общего объёма памяти в системе).
RemovedCallback и UpdateCallback
Очередной сюрприз. Оба свойства принимают делегаты, которые будут вызваны, как в случае обновления, так и в случае удаления элемента из кеша.
Если задуматься, то обновление, это по сути операция удаления, после которой сразу же следует операция добавления нового значения. Это объясняет, почему RemovedCallback срабатывает при обновлении элемента. А то что UpdateCallback срабатывает при удалении – просто факт из MSDN.
Различие же свойств заключается в том, что RemovedCallback должен вызываться после, а UpdateCallback – до фактического удаления элемента из кеша. Делегаты, хранимые в этих свойствах, принимают параметр, в котором содержится ссылка на кеш, ссылка на удаляемый элемент и причина удаления элемента.
Ещё один подарок хранится в реализации MemoryCache. В этом классе есть немного странная логика валидации переданного CacheItemPolicy параметра. Сначала она проверяет, что бы оба делегата не были заданы одновременно, иначе мы получим ArgumentException на этапе добавления элемента в кеш.
И всё бы ничего, если б для корректной работы свойства UpdateCallback было бы достаточно убедиться в отсутствии значения в свойстве RemovedCallback. Но по факту, мы всегда получаем ArgumentException на этапе добавления элемента при установке не пустого значения в UpdateCallback.
В итоге, единственно допустимое свойство для установки делегата сигнализирующего об изменениях в кеше является RemovedCallback (справедливо только для реализации MemoryCache).
Свойство ChangeMonitors
Данное свойство может хранить коллекцию объектов типа ChangeMonitor, каждый из которых может добавлять условия, при которых элемент будет удалён из кеша.
Кроме того, что мы можем создавать свои реализации абстрактного класса ChangeMonitor, в .Net Framework существуют следующие классы:
- CacheEntryChangeMonitor – следит за изменениями других элементов в том же экземпляре кеша
- FileChangeMonitor (HostFileChangeMonitor) – следит за изменениями файлов и папок в файловой системе
- SqlChangeMonitor – следит за изменениями в базе данных (достаточно медленный и редко применим на практике).
Важно помнить, что данное свойство в объекте CacheItemPolicy нужно задать до добавления элемента в кеш. Установка или изменение его для уже добавленного элемента не имеет никакого эффекта.
Заключение
Несмотря на ряд не самых очевидных особенностей в реализации MemoryCache, данный класс всё же является крайне полезным инструментом в арсенале разработчика, так как позволяет получить потоко-безопасную «железобетонно» работающую реализацию кеша с неплохими возможностями управления политиками инвалидации элементов. Уверен, что попытка написать свой аналог будет достаточно время затратной и наверняка не будет столь же эффективной.
Кэширование позволяет увеличивать производительность веб-приложений за счёт использования сохранённых ранее данных, вроде ответов на сетевые запросы или результатов вычислений. Благодаря кэшу, при очередном обращении клиента за одними и теми же данными, сервер может обслуживать запросы быстрее. Кэширование — эффективный архитектурный паттерн, так как большинство программ часто обращаются к одним и тем же данным и инструкциям. Эта технология присутствует на всех уровнях вычислительных систем. Кэши есть у процессоров, жёстких дисков, серверов, браузеров.
Ник Карник, автор материала, перевод которого мы сегодня публикуем, предлагает поговорить о роли кэширования в производительности веб-приложений, рассмотрев средства кэширования разных уровней, начиная с самого низкого. Он обращает особое внимание на то, где именно могут быть кэшированы данные, а не на то, как это происходит.
Мы полагаем, что понимание особенностей систем кэширования, каждая из которых вносит определённый вклад в скорость реакции приложений на внешние воздействия, расширит кругозор веб-разработчика и поможет ему в деле создания быстрых и надёжных систем.
Процессорный кэш
Начнём наш разговор о кэшах с самого низкого уровня — с процессора. Кэш-память процессора — это очень быстрая память, которая играет роль буфера между процессором (CPU) и оперативной памятью (RAM). Кэш-память хранит данные и инструкции, к которым обращаются чаще всего, благодаря чему процессор может получать ко всему этому доступ практически мгновенно.
В процессорах имеется особая память, представленная регистрами процессора, которая обычно представляет собой небольшое хранилище информации, обеспечивающее крайне высокую скорость обмена данными. Регистры — это самая быстрая память, с которой может работать процессор, которая расположена максимально близко к остальным его механизмам и имеет небольшой объём. Иногда регистры называют кэшем нулевого уровня (L0 Cache, L — это сокращение от Layer).
У процессоров, кроме того, имеется доступ к ещё нескольким уровням кэш-памяти. Это — до четырёх уровней кэша, которые, соответственно, называются кэшами первого, второго, третьего, и четвёртого уровня (L0 — L4 Cache). То, к какому именно уровню относятся регистры процессора, в частности, будет ли это кэш нулевого или первого уровня, определяется архитектурой процессора и материнской платы. Кроме того, от архитектуры системы зависит то, где именно — на процессоре, или на материнской плате, физически расположена кэш-память разных уровней.
Структура памяти в некоторых новейших CPU
Кэш жёсткого диска
Жёсткие диски (HDD, Hard Disk Drive), применяемые для постоянного хранения данных — это, в сравнении с оперативной памятью, предназначенной для кратковременного хранения информации, устройства довольно медленные. Однако надо отметить, что скорость постоянных хранилищ информации увеличивается благодаря распространению твердотельных накопителей (SSD, Solid State Drive).
В системах долговременного хранения информации кэш диска (его ещё называют буфером диска или кэширующим буфером) — это встроенная в жёсткий диск память, которая играет роль буфера между процессором и физическим жёстким диском.
Кэш жёсткого диска
Дисковые кэши работают, исходя из предположения, что когда на диск что-то пишут, или с него что-то читают, есть вероятность того, что в ближайшем будущем к этим данным будут обращаться снова.
О быстродействии жёстких дисков и оперативной памяти
Разница между временным хранением данных в оперативной памяти и постоянным хранением на жёстком диске проявляется в скорости работы с информацией, в стоимости носителей и в близости их к процессору.
Время отклика оперативной памяти составляет десятки наносекунд, в то время как жёсткому диску нужны десятки миллисекунд. Разница в быстродействии дисков и памяти составляет шесть порядков!
Одна миллисекунда равна миллиону наносекунд
Простой веб-сервер
Теперь, когда мы обсудили роль кэширования в базовых механизмах компьютерных систем, рассмотрим пример, иллюстрирующий применение концепций кэширования при взаимодействии клиента, представленного веб-браузером, и сервера, который, реагируя на запросы клиента, отправляет ему некие данные. В самом начале у нас имеется простой веб-сервер, который, отвечая на запрос клиента, считывает данные с жёсткого диска. При этом представим, что между клиентом и сервером нет никаких особых систем кэширования. Вот как это выглядит.
Простой веб-сервер
При работе вышеописанной системы, когда клиент обращается напрямую к серверу, а тот, самостоятельно обрабатывая запрос, читает данные с жёсткого диска и отправляет клиенту, без кэша всё-таки не обходится, так как при работе с диском будет задействован его буфер.
При первом запросе жёсткий диск проверит кэш, в котором, в данном случае, ничего не будет, что приведёт к так называемому «промаху кэша». Затем данные считаются с самого диска и попадут в его кэш, что соответствует предположению, касающемуся того, что эти данные могут понадобиться снова.
При последующих запросах, направленных на получение тех же данных, поиск в кэше окажется успешным, это — так называемое «попадание кэша». Данные в ответ на запрос будут поступать из дискового буфера до тех пор, пока они не будут перезаписаны, что, при повторном обращении к тем же данным, приведёт к промаху кэша.
Кэширование баз данных
Усложним наш пример, добавим сюда базу данных. Запросы к базам данных могут быть медленными и требовать серьёзных системных ресурсов, так как серверу баз данных, для формирования ответа, нужно выполнять некие вычисления. Если запросы повторяются, кэширование их средствами базы данных поможет уменьшить время её отклика. Кроме того, кэширование полезно в ситуациях, когда несколько компьютеров работают с базой данных, выполняя одинаковые запросы.
Простой веб-сервер с базой данных
Большинство серверов баз данных по умолчанию настроены с учётом оптимальных параметров кэширования. Однако, существует множество настроек, которые могут быть модифицированы для того, чтобы подсистема баз данных лучше соответствовала особенностям конкретного приложения.
Кэширование ответов веб-сервера
Продолжим развивать наш пример. Теперь веб-сервер, раньше рассматриваемый как единая сущность, разбит на две части. Одна из них, собственно веб-сервер, теперь занимается взаимодействием с клиентами и с серверным приложением, которое уже работает с системами хранения данных. Веб-сервер можно настроить так, чтобы он кэшировал ответы, в результате ему не придётся постоянно отправлять серверному приложению похожие запросы. Похожим образом, основное приложение может кэшировать некоторые части собственных ответов на ресурсоёмкие запросы к базе данных или на часто встречающиеся запросы файлов.
Кэш ответов и кэш приложения
Ответы веб-сервера кэшируются в оперативной памяти. Кэш приложения может храниться либо локально, в памяти, либо на специальном кэширующем сервере, который использует базу данных, вроде Redis, которая хранит данные в оперативной памяти.
Мемоизация функций
Сейчас поговорим об оптимизации производительности серверного приложения за счёт мемоизации. Это — разновидность кэширования, применяемая для оптимизации работы с ресурсоёмкими функциями. Данная техника позволяет выполнять полный цикл вычислений для определённого набора входных данных лишь один раз, а при следующих обращениях к функции с теми же входными данными сразу выдавать найденный ранее результат. Мемоизация реализуется посредством так называемых «таблиц поиска» (lookup table), хранящих ключи и значения. Ключи соответствуют входным данным функции, значения — результатам, которые возвращает функция при передаче ей этих входных данных.
Мемоизация функции с помощью таблицы поиска
Мемоизация — это обычный приём, используемый для повышения производительности программ. Однако он может быть не особенно полезным при работе с ресурсоёмкими функциями, которые вызываются редко, или с функциями, которые, и без мемоизации, работают достаточно быстро.
Кэширование в браузере
Теперь перейдём на сторону клиента и поговорим о кэшировании в браузерах. В каждом браузере имеется реализация HTTP-кэша (его ещё называют веб-кэшем), который предназначен для временного хранения материалов, полученных из интернета, таких, как HTML-страницы, JavaScript-файлы и изображения.
Этот кэш используется, когда в ответе сервера содержатся правильно настроенные HTTP-заголовки, указывающие браузеру на то, когда и на какое время он может кэшировать ответ сервера.
Перед нами весьма полезная технология, которая даёт следующие преимущества всем участникам обмена данными:
- Улучшаются впечатления пользователя от работы с сайтом, так как ресурсы из локального кэша загружаются очень быстро. Во время получения ответа не входит время прохождения сигнала от клиента к серверу и обратно (RTT, Round Trip Time), так как запрос не уходит в сеть.
- Уменьшается нагрузка на серверное приложение и на другие серверные компоненты, ответственные за обработку запросов.
- Высвобождается некоторая часть сетевых ресурсов, которыми теперь могут воспользоваться другие пользователи интернета, экономятся средства на оплату трафика.
Кэширование в браузере
Кэширование и прокси-серверы
В компьютерных сетях прокси-серверы могут быть представлены специальным аппаратным обеспечением или соответствующими приложениями. Они играют роль посредников между клиентами и серверами, хранящими данные, которые этим клиентам требуются. Кэширование — это одна из задач, которую они решают. Рассмотрим различные виды прокси-серверов.
▍Шлюзы
Шлюз (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). Например, если вы посещаете популярный веб-сайт и загружаете какие-нибудь статические данные, они попадают в кэш. Каждый следующий пользователь, запросивший те же данные, получит их, до истечения срока их кэширования, с кэширующего сервера. Эти серверы, определяя актуальность информации, ориентируются на серверы, хранящие исходные данные.
Прокси-серверы в инфраструктуре обмена данными между клиентом и сервером
Итоги
В этом материале мы рассмотрели различные уровни кэширования данных, применяющиеся в процессе обмена информацией между клиентом и сервером. Веб-приложения не могут мгновенно реагировать на воздействия пользователя, что, в частности, связано, для действий, требующих обмена данными с серверами этих приложений, с необходимостью выполнения неких вычислений перед отправкой ответа. Во время, необходимое для передачи данных от сервера клиенту, входит и время, необходимое для поиска необходимых данных на диске, и сетевые задержки, и обработка очередей запросов, и механизмы регулирования полосы пропускания сетей, и многое другое. Если учесть, что всё это может происходить на множестве компьютеров, находящихся между клиентом и сервером, то можно говорить о том, что все эти задержки способны серьёзно увеличить время, необходимое для прихода запроса на сервер и получения клиентом ответа.
Правильно настроенная система кэширования способна значительно улучшить общую производительность сервера. Кэши сокращают задержки, неизбежно возникающие при передаче данных по сети, помогают экономить сетевой трафик, и, в результате, уменьшают время, необходимое для того, чтобы браузер вывел запрошенную у сервера веб-страницу.
Уважаемые читатели! Какие технологии кэширования вы используете в своих проектах?
Стратегия кеширования в приложении / Хабр
Когда заходит разговор о кешировании складывается парадоксальная ситуация. С одной стороны все понимают важность и нужность кеширования в архитектуре приложений. С другой стороны мало кто может внятно объяснить что и как надо кешировать.
Обычно люди сходу начинают предлагать готовые реализации кеша, вроде memcached или HTTP-кеша, но это лишь ответ на вопрос где кешировать.
Кеширование – одна из многих тем, наряду с безопасностью и логированием, о которых знают и говорят все, но мало кто может это сделать правильно.
Зачем нужен кеш
Кеш приближает данные к месту их использования. В современном мире, состоящим на 98% из интернета, данные обычно лежат очень далеко от пользователя. На всем пути от хранилища к пользователю есть кеши, которые служат только одной цели – чтобы пользователь как можно быстрее получил свои данные.
Если рассмотреть внимательнее, то видно, что драгоценное время тратится на обработку данных в поставщике и передачу данных от поставщика клиенту, время обработки данных на клиенте тут не учитываем.
При наличии высоких нагрузок кеширование просто необходимо. Оно позволяет обслуживать больше клиентов, с теми же ресурсами, потому что поставщики данных больше отдыхают. Но даже при невысоких нагрузках кеширование положительно влияет на отзывчивость приложения.
Кеш нельзя просто включить
Одно из основных заблуждений насчет кеширования заключается в том, что многие думают что кеш можно просто включить.
На заре своей карьеры программиста я один раз просто так включил кеширование, буквально через час пришлось его выключить. Тогда я нарвался на основную проблему при кешировании – устаревание данных. Пользователь после изменения данных не видел результата 15 минут.
Очень важно понимать что и как вы собираетесь кешировать, чтобы не нарушать логику работы приложения. И первый вопрос, на который вам необходимо ответить – насколько устаревшие данные можно отдавать клиенту. Естественно можно сделать свой кеш для каждого клиента, это упростит решение вопроса об актуальности данных, но принесет много других проблем.
Типы кеширования
Есть три основных типа кеширования по механике работы:
- Lazy cache, он же ленивый кеш, он же тупой кеш – самый простой в реализации тип кеширования, зачастую встроен в фреймворки. Кеш просто сохраняет данные и отдает их пока не устареет.
- Synchronized cache, синхронизированный кеш – клиент вместе с данными получается метку последнего изменения и может спросить у поставщика не изменились ли данные, чтобы повторно из не запрашивать. Такой тип кеширования позволяет всегда иметь свежие данные, но очень сложен в реализации.
- Write-through cache, или кеш сквозной записи – любое изменение данных выполняется сразу в хранилище и в кеше. Этот тип кеша может никогда не устаревать, но возникают проблемы с так называемой “когерентностью”.
Наверное можно придумать и другие типы кешей, но я не встречал.
Устаревание и когерентность кеша
Объем кеша всегда ограничен. Зачастую он меньше объема данных, которые в этот кеш можно положить. Поэтому элементы, помещенные в кеш, рано или поздно будут вытеснены. Современные фреймворки для кеширования позволяют очень гибко управлять устареванием, учитывая приоритеты, время устаревания, объемы данных итд.
Если одни и те же данные попадают в разные кеши, то возникает проблема когерентности кеша. Например одни и те же данные используются для формирования разных страниц и кешируются страницы. Страницы сформированные позже будут содержать обновленные данные, а страницы, закешированные раньше, будут содержать устаревшие данные. Таким образом будет нарушена согласованность поведения.
Простой способ поддержания когерентности – принудительное устаревание (сброс) кеша при изменении данных. Поэтому увеличение памяти для кеша, чтобы он меньше устаревал, не всегда хорошая идея.
Эффективность кеша
Основной параметр, который характеризует систему кеширования – это процент попаданий запросов в кеш. Этот параметр довольно легко измерить, чтобы понять насколько ваша система кеширования эффективна.
Частые сбросы кеша, кеширование редко запрашиваемых данных, недостаточный объем кеша – все это ведет к пустой трате оперативной (обычно) памяти, не повышая эффективность работы.
Иногда данные меняются настолько часто и непредсказуемо, что кеширование не даст эффекта, процент попаданий будет близок к нулю. Но обычно данные считываются гораздо чаще, чем записываются, поэтому кеши эффективны.
Применение разных типов кеширования
Ленивый кеш
Это самый простой вид кеширования, но его нужно использовать осторожно, так как отдает устаревшие данные. Можно при каждой записи сбрасывать ленивый кеш, чтобы поддерживать актуальность данных, но тогда затраты на реализацию будут сравнимы с более сложными типами кеширования.
Такой тип кеширования можно использовать для данных, которые почти никогда не меняются. Другой вариант использования – делать ленивый кеш с небольшим временем устаревания для стабильной работы при всплесках нагрузки.
Такой тип кеширования позволит быстрее всех дать ответ.
Синхронизированный кеш
Это самый полезный тип кеширования, так как отдает свежие данные и позволяет реализовать многоуровневый кеш.
Такой тип кеширования встроен в протокол HTTP. Сервер отдает метку изменения, а клиент кеширует у тебя результат и в последующем запросе передает эту метку. Сервер может дать ответ, что состояние не изменилось и можно использовать кешированный на клиенте объект. Сервер в свою очередь, получив метку может переспросить у хранилища были ли изменения или нет.
Этот тип кеширования не избавляет от накладных расходов на общение между системами. Поэтому часто дополняется другими типами кеширования, чтобы ускорить работу.
Кеш сквозной записи
Если есть система распределенного кеширования (memcached, Windows Sever App Fabric, Azure Cache), то можно использовать кеш сквозной записи. Рукопашная реализация синхронизации кешей между узлами сама по себе отдельный большой проект, потому не стоит заниматься ей в рамках разработки приложения.
Не стоит пытаться кешировать все в синхронизированном кеше, иначе большая часть кода приложения будет заниматься перестройкой кеша.
Также не стоит забывать что системы распределенного кеширования также требуют общения между системами, что может сказываться на быстродействии.
Что еще нужно учитывать в стратегии кеширования
Выбирайте правильную гранулярность кешируемых данных. Например кеширование данных для каждого пользователя скорее всего будет неэффективно при большом количестве пользователей. Если кешировать данные для всех пользователей разом, то возникнут проблемы с устареванием данных и когерентностью кеша.
Кешируйте данные как можно позже, непосредственно перед отдачей во внешнюю систему. Кешировать данные, полученные извне, необходимо только в случае проблем с производительностью на этом этапе. Внешние хранилища, такие как СУБД и файловые системы, сами реализуют кеширование, поэтому обычно нет смысла кешировать результаты запросов.
Не нужно городить свои велосипеды для кеширования в приложениях, обычно уже есть готовые инструменты и надо уметь ими пользоваться.
Заключение
Надеюсь статья была интересной и полезной для вас. Комментируйте, оценивайте, буду рад любым предложениям.
Cash vs. Cache
Английский — сложный язык. В английском есть несколько слов, которые звучат одинаково, но имеют разное написание и значение. Эти слова называются гомофонами и являются причиной путаницы для многих молодых учеников и местных жителей. Денежные средства и кэш являются примером пары гомофонов, которые звучат одинаково. Многие люди произносят кеш как кайше или качай, но правильное произношение кеша точно так же, как и наличные.
Хотя наличные — очень распространенное слово, кэширование может быть новым словом для многих здесь, поэтому мы обсудим оба из них подробно.
Происхождение:
Денежные средства поступили в конце 16-го века (обозначая коробку для денег): из «старой французской» или итальянской кассы «box», из латинского capsa (см. Case2).
Наличные как существительное:
Денежные средства используются как существительные, что означает деньги в монетах или банкнотах, в отличие от чеков, денежных переводов или кредита.
сотрудников были оплачены наличными.
Кэш как существительное:
Кэш также используется как существительное в английском языке, что означает набор предметов одного типа, хранящихся в скрытом или недоступном месте.
Мы подошли к тайнику с оружием.
На языке компьютеров вспомогательная память, из которой возможен высокоскоростной поиск, называется кешем.
Типичные размеры кэша варьируются от 64К до 256К.
Примеры :
Вы успешно сбросили кэш своего App Store, освободив временное хранилище, которое может привести к замедлению работы телефона или невозможности обновления приложений. (Business Insider)
Отряд Национальной народной армии (АНП) в пятницу обнаружил тайник с минометными снарядами, двумя автоматами Калачникова и важным количеством боеприпасов, говорится в коммюнике Министерства национальной обороны (MDN).(Алжир Пресс Пресс)
Йеменские силы безопасности захватили большой склад оружия в районе Ад-Тавахи в Адене, районе, где нелегальные вооруженные группировки широко представлены. (Национальный)
Пенсионные консультанты говорят, что некоторые управляющие фондами рассматривают возможность вкладывать еще больше своих активов в наличные, ожидая, пока рынки успокоятся. (The Wall Street Journal)
Следователи говорят, что Говард возьмет чеки, выставленные в гольф-клуб Jacaranda, положит их в кассу внутри про-магазина магазина, но введет сумму, которая меньше номинальной стоимости чека.(Солнце-Страж)
Философия программы денежных переводов Project Issara проста: никто не знает о потребностях жертв торговли людьми лучше, чем сами жертвы. (Крисчен Сайенс Монитор)
Наличные или кэш:
Тайник — это укрытие, особенно в земле, для боеприпасов, еды, сокровищ и т. Д .; область памяти компьютера, предназначенная для быстрого поиска часто используемых или запрашиваемых данных. Деньги — это деньги в виде монет или банкнот, особенно выпущенные правительством.Кэш и кеш объявляются одинаково, но имеют разное написание и значения. Распространенной ошибкой в написании является запись «кеш» как «наличные».
Украденные деньги были найдены в кеше, найденном в информации, найденной в кеше компьютера.
Получите это? Мы не обвиняем вас!
,
кеширование — PHP APC Кешировать или не кешировать?
Переполнение стека
Товары
- Клиенты
- Случаи использования
Переполнение стека
Публичные вопросы и ответыКоманды
Частные вопросы и ответы для вашей командыпредприятие
Частные вопросы и ответы для вашего предприятияработы
Программирование и связанные с ним технические возможности карьерного ростаТалант
Нанимать технический талантреклама
Связаться с разработчиками по всему миру
,
Cache-Control — веб-технология для разработчиков
HTTP-заголовок Cache-Control содержит директив (инструкции) для кэширования как запросов, так и ответов. Данная директива в запросе не означает, что такая же директива должна быть в ответе.
Синтаксис
В директивах
кэширования действуют следующие правила:
- Без учета регистра, но рекомендуется использовать строчные буквы.
- Несколько директив разделены запятыми.
- Некоторые директивы имеют необязательный аргумент, который может быть либо токеном , либо цитируемой строкой . (См. Спецификации для определения)
Директивы запроса кеша
Стандартные директивы Cache-Control , которые могут использоваться клиентом в HTTP-запросе.
Cache-Control: максимальный возраст = <секунд> Cache-Control: max-stale [= <секунд>] Cache-Control: min-fresh = <секунд> Cache-Control: без кеша Cache-Control: нет магазина Cache-Control: без преобразования Cache-Control: только если кэшируется
кеш ответ директивы
Стандартные директивы Cache-Control , которые могут использоваться сервером в ответе HTTP.
Cache-Control: необходимо переоценить Cache-Control: без кеша Cache-Control: нет магазина Cache-Control: без преобразования Cache-Control: общедоступный Cache-Control: приватный Cache-Control: прокси-ревалидат Cache-Control: max-age = <секунд> Cache-Control: s-maxage = <секунд>
Расширение Cache-Control директивы
Расширение
Директивы Cache-Control не являются частью основного документа стандартов HTTP-кэширования. Проверьте таблицу совместимости для их поддержки; пользовательские агенты, которые их не распознают, должны их игнорировать.
Cache-Control: неизменяемый Cache-Control: stale-while-revalidate = <секунд> Cache-Control: stale-if-error = <секунд>
Директивы
Кешируемость
Ответ обычно кэшируется браузером, если:
- имеет код состояния
301,302,307,308или410и -
Cache-Controlне имеетбез храненияили , если прокси , не имеетчастныхи -
Авторизацияне установлена - имеет код состояния
301,302,307,308или410или - имеет
общедоступных,max-ageилиs-maxageвCache-Controlили - имеет
Истекаетустановлен
- имеет код состояния
Либо
-
публичный - Ответ может быть сохранен в любом кэше , даже если ответ обычно не кэшируется.
-
частный - Ответ может храниться только в кэше браузера , даже если ответ обычно не кэшируется. Если вы не хотите хранить ответ в каком-либо кэше, используйте вместо него
no-store. Эта директива неэффективна для предотвращения хранения вашего ответа кешами. -
без кэширования - Ответ может быть сохранен в любом кэше , даже если ответ обычно не кэшируется.Тем не менее, сохраненный ответ ДОЛЖЕН всегда пройти проверку на сервере происхождения, прежде чем использовать его, поэтому вы не можете использовать
без кэшированияв сочетании снеизменяемым. Если вы не хотите хранить ответ в каком-либо кэше, используйте вместо негоno-store. Эта директива неэффективна для предотвращения хранения вашего ответа кешами. -
без магазина - Ответ , а не , может быть сохранен в любого кэша.Хотя могут быть установлены и другие директивы, только эта является единственной директивой, которая вам нужна для предотвращения кэшированных ответов в современных браузерах.
max-age = 0уже подразумевается . Настройкаmust-revalidateне имеет смысла , потому что для того, чтобы пройти повторную валидацию, вам нужно сохранить ответ в кеше, которыйno-storeпредотвращает.
Срок действия
-
max-age = <секунд> - Максимальное время, в течение которого ресурс считается свежим.В отличие от
Expires, эта директива относится ко времени запроса. -
s-maxage = <секунд> - Переопределяет
max-ageилиExpires заголовок, но только для общих кэшей (например, прокси). Игнорируется частными кешами. -
max-stale [= <секунд>] - Указывает, что клиент примет устаревший ответ. Необязательное значение в секундах указывает на верхний предел устаревания, который примет клиент.
-
min-fresh = <секунд> - Указывает, что клиент хочет, чтобы ответ, который все еще был свежим для по крайней мере указанное количество секунд.
-
stale-while-revalidate = <секунд> - Указывает, что клиент примет устаревший ответ при асинхронной проверке в фоновом режиме нового. Значение секунд указывает, как долго клиент будет принимать устаревший ответ. См. «Обновление
устаревших» для получения дополнительной информации. -
stale-if-error = <секунд> - Указывает, что клиент примет устаревший ответ, если проверка для нового не удалась. Значение секунд указывает, как долго клиент будет принимать устаревший ответ после первоначального истечения срока действия.
Повторная проверка и перезагрузка
-
необходимо подтвердить - Указывает, что после того, как ресурс устарел, кэши не должны использовать свою устаревшую копию без успешной проверки на исходном сервере.
-
прокси-ревалидат - Как и
, необходимо повторно подтвердить, но только для совместно используемых кэшей (например, прокси). Игнорируется частными кешами. -
неизменяемый - Указывает, что тело ответа не изменится с течением времени. Ресурс, если не истек , не изменяется на сервере, и поэтому клиент не должен отправлять для него условную повторную проверку (например,
If-None-MatchилиIf-Modified-Since) для проверки обновлений, даже когда пользователь явно обновляет страницу.Клиенты, которые не знают об этом расширении, должны игнорировать их согласно спецификации HTTP. В Firefox неизменнойhttps: //транзакций. Для получения дополнительной информации см. Также этот блог.
Другое
-
без преобразования - Промежуточный кеш или прокси-сервер не может редактировать тело ответа,
Content-Encoding,Content-RangeилиContent-Type. Поэтому он запрещает функции прокси или браузера, такие как Google Web Light, конвертировать изображения для минимизации данных для кеш-хранилища или медленного соединения. -
только при кешировании - Установите для клиента , чтобы указать «не использовать сеть» для ответа. Кэш должен либо отвечать сохраненным ответом, либо отвечать кодом состояния
504. Условные заголовки, такие какIf-None-Matchне должны быть установлены. Нет никакого эффекта, еслитолько-если-кэшированныйустановлен сервером как часть ответа.
Примеры
Предотвращение кеширования
Чтобы отключить кэширование ресурса, вы можете отправить следующий заголовок ответа:
- Хорошо:
Cache-Control: нет магазина
- Плохо:
Cache-Control: частный, без кеша, без хранилища, max-age = 0, обязательная повторная проверка, предварительная проверка = 0, пост-проверка = 0
Кэширование статических активов
Для файлов в приложении, которые не изменятся, вы обычно можете добавить агрессивное кэширование, отправив заголовок ответа ниже.Это включает в себя статические файлы, которые обслуживаются приложением, например, изображения, файлы CSS и файлы JavaScript. Кроме того, см. Также заголовок Expires .
Cache-Control: общедоступный, max-age = 604800, неизменяемый
Требуется повторная проверка
Указание без кэширования или max-age = 0 указывает, что клиенты могут кэшировать ресурс и должны каждый раз проходить повторную проверку перед его использованием. Это означает, что HTTP-запрос происходит каждый раз, но он может пропустить загрузку тела HTTP, если содержимое допустимо.
Cache-Control: без кеширования Cache-Control: без кеша, max-age = 0
Технические характеристики
Совместимость браузера
См. Также
,
Что такое кэш?
Обновлено: 10/11/2017 от Computer Hope
Кэш может относиться к любому из следующего:
1. Произносится как физическая форма денег, кэш — это область высокоскоростного доступа, которая является зарезервированной частью основной памяти или областью на устройстве хранения. Два основных типа кэша: кэш-памяти и кэш-памяти .
Кэш-память является частью высокоскоростной SRAM (статической оперативной памяти) и действует, потому что большинство программ обращаются к одним и тем же данным или инструкциям неоднократно.Сохраняя как можно больше этой информации в SRAM, компьютер избегает доступа к более медленной DRAM, благодаря чему компьютер работает быстрее и эффективнее. Сегодня большинство компьютеров поставляются с кэш-памятью L3 или L2, в то время как на старых компьютерах используется только кэш-память L1. Ниже приведен пример процессора Intel i7 и его общего кэша L3.
2. В интернет-браузерах кэш — это временное хранилище, где хранятся данные веб-сайта. Кэшируя эти данные, веб-браузер может повысить производительность, загружая данные с вашего диска, а не из Интернета, если это когда-либо понадобится снова.В большинстве случаев каждый раз, когда вы открываете веб-страницу, страница и все ее файлы отправляются во временный кеш браузера на жестком диске. Если веб-страница или ее ресурсы не изменились с момента последнего просмотра, браузер загружает данные из кэша, а не загружает файлы снова. Кэш-память экономит много времени, особенно если вы используете модем, а также может помочь сэкономить пропускную способность для владельца веб-сайта.
Наконечник
Любой, кто обеспокоен своей конфиденциальностью или хочет скрыть посещенные страницы, может очистить свой интернет-кеш.Если вы часто очищаете кеш вашего интернет-браузера, вы можете также рассмотреть возможность использования режима инкогнито.
3. Подобно кешированию памяти , дискового кеширования используется для доступа к часто используемым данным. Однако вместо использования высокоскоростной SRAM дисковый кеш использует обычную основную память. Последние данные с диска хранятся в буфере памяти. Когда программе требуется доступ к данным с диска, она сначала проверяет дисковый кэш, чтобы увидеть, есть ли данные. Кэширование диска может значительно повысить производительность приложений, поскольку доступ к байту данных в ОЗУ может быть в тысячи раз быстрее, чем доступ к нему на жестком диске.
4. Сервер кэширования — это компьютер или сетевое устройство, настроенное для хранения веб-страниц, к которым обращались пользователи в сети. Любому пользователю, пытающемуся получить доступ к веб-странице, хранящейся на сервере кэша, отправляется сохраненная версия, а не загружается веб-страница снова. Кэш-серверы помогают снизить перегрузку сетевого и интернет-трафика, а также сэкономить компании на затратах на пропускную способность.
Буфер, Условия базы данных, Условия аппаратного обеспечения, История, L1, L2, L3, Условия памяти, Прокси-сервер, Сервер, Файл подкачки, Тег, Условия веб-дизайна, Кэш обратной записи
,
Добавить комментарий