Инвалидация кэша что это
На сегодняшний день время отклика на запрос является критичной метрикой для любого проекта. Пользователи не очень любят, когда web-страница формируется долго (несколько секунд или дольше). Поэтому разработчики стремятся уменьшить время ответа на запрос клиента, для чего прибегают к кэшированию.
Представим, что разрабатывается торговая платформа и есть личный кабинет с аналитикой сделок пользователя. Нужно выводить количество сделок, прибыль, средний оборот и тд. Большинство метрик являются агрегационными, то есть их нужно высчитывать. Если использовать только РСУБД, то среднее время ответа будет сотни миллисекунд, а при большой нагрузке — секунды. Можно подключить подходящие аналитические базы данных, но чаще всего это слишком дорого в средних проектах.
Самая распространенная практика решения сегодня — это кэш. Сложные вычисления кэшируются, то есть записываются в оперативную память. Обращение к оперативной памяти займет сотни наносекунд, примерно в миллион раз быстрее, чем вычислить данные из РСУБД. Новая схема взаимодействия будет включать кэширующий сервер. Алгоритм следующий:
- клиент делает запрос
- бекенд проверяет кэш. Если значение есть в кэше, то оно просто возвращается клиенту
- если значения в кэше нет, то сервер вычисляет все из базы, записывает числа в кэш и отдает клиенту. Теперь все последующие запросы будут возвращать результаты вычислений из кэша
Подход №1: карты импорта
Карты импорта — это простейшее решение проблемы каскадной инвалидации кэшей. Кроме того, этот механизм легче всего реализовать. Но он, к сожалению, поддерживается лишь в Chrome (эту возможность, к тому же, нужно явным образом включать).
Несмотря на это я хочу начать именно с рассказа о картах импорта, так как уверен в том, что это решение станет в будущем наиболее распространённым. Кроме того, описание работы с картами импорта поможет объяснить и особенности других подходов к решению нашей проблемы.
Использование карт импорта для предотвращения каскадной инвалидации кэша состоит из трёх шагов.
▍Шаг 2
Нужно воспользоваться инструментом, наподобие rev-hash, и сгенерировать с его помощью копию каждого файла, к имени которого добавлен хэш, указывающий на версию его содержимого.
После того, как эта часть работы выполнена, содержимое выходной директории должно будет выглядеть примерно так, как показано ниже (обратите внимание на то, что там теперь присутствует по два варианта каждого файла):
Redis как кэш
Redis чаще всего используют именно как кэширующий сервер. Он имеет богатый встроенный функционал для этих целей. Рассмотрим основные команды, с помощью которых кэшируют значения в Redis.
Инвалидация кэша в базах данных
Каждая из подобных систем предоставляет свои собственные методы уничтожения кэша. Обратитесь к их документации, чтобы узнать больше.
Теперь перейдем к вопросу, почему начинающим разработчикам приходится с этим бороться. Как правило, в современных стеках технологий применяются все три вида кэширования. И иногда разработчики застревают при отладке.
Представьте, что вы внесли некоторые изменения в свой веб-сайт, но они не отображаются. Если предположить, что с кодом все в порядке, виновником этого может быть любой из трех вышеописанных видов кэширования. Но это относительно небольшой недостаток (даже не недостаток, если вы о нем знаете) по сравнению с огромным положительным эффектом, который дает кэширование. Этот эффект выражен в масштабируемости, меньшем времени отклика и в целом лучшем пользовательском интерфейсе.
Сети доставки контента (CDN)
Сеть доставки контента (CDN) способна на больше, чем просто кэширование. Она хранит данные в географически распределенных местах, из-за чего время приема и передачи в конкретный географически локализованный браузер и обратно сокращается. Благодаря этому ваш браузер получает данные из ближайшего к вам узла сети CDN.
CDN следует тем же правилам, что и ваш браузер, и фактически просто становится еще одним посредником. Если срок действия кэша еще не истек, первый запрос от браузера в определенном временном окне достигает сервера, а затем последующие запросы уже будут обслуживаться из самой CDN.
Данный тип кэширования не только помогает сократить время отклика, но и снижает нагрузку на ваш сервер.
Инвалидация кэша
Любой кэш может стать неактуальным раньше времени жизни. В нашем примере со сделками это может произойти при возникновении новой сделки у пользователя. В этом случае нужно удалить ключ в кэше, чтобы при следующем запросе произошел пересчет значения. Может возникнуть вопрос: а почему бы просто не добавить значение в имеющийся ключ? В данном примере это было бы наилучшим решением, но действовать необходимо не «в лоб». При увеличении значения двумя командами get + set может получиться неконсистентное состояние (подробнее эта проблема будет рассмотрена в следующем уроке). Также обновление значения не всегда возможно, например, в случае если значение — это среднее арифметическое.
Удаление ключа происходит командой del :
Вернувшееся значение 1 означает, что ключ существовал и был успешно удален. Если ключа не было, то вернулся бы 0.
Иногда требуется удалить тысячи ключей за раз. Например, у поставщика цен на акции произошел сбой и все сделки за период сбоя оказались недействительными. В этом случае нельзя использовать N вызовов команды del , потому что это будет выполняться очень долго и заберет все ресурсы Redis. Для множественного удаления существует команда unlink , которую можно безопасно использовать в продакшен-среде:
Все ключи для удаления указываются через пробел. Стоит учитывать, что ключи удаляются асинхронно, то есть могут существовать после unlink короткий промежуток времени.
Инвалидация кеша, возможно, одна из самых запутанных вещей в программировании. Тонкость вопроса состоит в компромиссе между полнотой, избыточностью и сложностью этой процедуры. Так о чём же эта статья? Хотелось бы не привязываясь к какой-либо платформе, языку или фреймворку, подумать о том как следует реализовывать систему инвалидации. Ну а чтобы не писать обо всём и ни о чём, сконцентрируемся на кешировании результатов SQL-запросов построенных с помощью ORM, которые в наше время встречаются нередко.
Полнота и избыточность
Начнём всё же с общих соображений не специфичных ни для SQL-запросов, ни для ORM. Упомянутые полноту и избыточность я определяю следующим образом. Полнота инвалидации — это её характеристика, определяющая насколько часто и в каких случаях может/будет возникать ситуация когда в кеше будут содержаться грязные данные и как долго они там будут оставаться. Избыточностью, в свою очередь, назовём то как часто кеш будет инвалидироваться без необходимости.
Рассмотрим для примера распространённый способ инвалидации по времени. С одной стороны, он практически гарантирует, что сразу после изменения данных кеш грязен. С другой стороны, время которое кеш остаётся грязным, мы можем легко ограничить уменьшив время жизни (что в свою очередь сократит процент попаданий). Т.е. при сокращении времени жизни кеша полнота инвалидации улучшается, а избыточность ухудшается. В итоге, чтобы достигнуть идеальной полноты инвалидации (никаких грязных данных) мы должны выставить таймаут в 0, или, другими словами, отключить кеш. Во многих случаях временное устаревание данных в кеше допустимо. Например, как правило, не так уж и страшно если новость в блоке последних новостей появится там на несколько минут позже или общее количество пользователей вашей социальной сети будет указано с ошибкой в пару-тройку тысяч.
Инвалидация по событию
Способ с инвалидацией по времени хорош своей простотой, однако, не всегда применим. Что ж, можно сбрасывать кеш при изменении данных. Одной из проблем при таком подходе является то, что при добавлении нового запроса, который мы кешируем приходиться добавлять код для его инвалидации в при изменении данных. Если мы используем ORM, то данные изменяются (в хорошем случае) в одном месте — при сохранении модели. Наличие одного центрального кода изменения данных облегчает задачу, однако, при большом количестве разнообразных запросов приходиться всё время дописывать туда всё новые и новые строки сброса различных кусочков кеша. Таким образом, мы получаем на свою голову избыточную связность кода. Пора её ослабить.
Воспользуемся событиями — ORM при сохранении/удалении модели будет события генерировать, а мы при кешировании чего-либо будем тут же и вешать обработчик на соответствующее событие, удаляющий это что-либо из кеша. Всё отлично, однако, написание большого количества похожих обработчиков утомляет, плюс логика приложения зарастает логикой кеширования/инвалидации как свинья жиром.
Автоматическая инвалидация ORM-запросов
Вспомним, что у нас есть ORM, а для него каждый запрос представляет не просто текст, а определённую структуру — модели, дерево условий и прочее. Так что, по идее, ORM может и кешировать и вешать инвалидационные обработчики прямо при кешировании по мере надобности. Чертовски привлекательное решение для ленивых ребят, вроде меня.
Небольшой пример. Допустим мы выполняем запрос:
и кешируем его. Очевидно, нам нужно сбросить запрос если при добавлении/обновлении/удалении поста для его старой или новой версии выполняется условие category_id=2 and published=true . Через некоторое время для каждой модели образуются списки инвалидаторов, каждый из которых хранит список запросов, которые должен сбрасывать:
post:
category_id =2 and published = true :
select * from post where category_id =2 and published
select count ( * ) from post where category_id =2 and published
select * from post where category_id =2 and published limit 20
category_id =3 and published = true :
select * from post where category_id =3 and published limit 20 offset 20
category_id =3 and published = false :
select count ( * ) from post where category_id =3 and not published
foo:
a =1 or b =10 :
or_sql
a in ( 2 , 3 ) and b =10 :
in_sql
a >1 and b =10 :
gt_sql
и т.д.
В реальности в инвалидаторах удобнее хранить списки ключей кеша, а не тексты запросов, тексты здесь для наглядности.
Посмотрим, что будет происходить при добавлении объекта. Мы должны пройти по всему списку инвалидаторов и стереть ключи кеша для условий, выполняющихся для добавленного объекта. Но инвалидаторов может быть много, и храниться они должны там же где сам кеш, т.е. скорее всего не в памяти процесса и загружать их все каждый раз не хотелось бы, да и последовательная проверка всех условий больно долга.
Очевидно, нужно как-то группировать и отсеивать инвалидаторы без их полной проверки. Заметим, что картина когда условия различаются только значениями. Например, инвалидаторы в модели post все имеют вид category_id=? and published=. Сгруппируем инвалидаторы из примера по схемам:
post:
category_id =? and published =? :
2 , true :
select * from post where category_id =2 and published
select count ( * ) from post where category_id =2 and published
select * from post where category_id =2 and published limit 20
3 , true :
select * from post where category_id =3 and published limit 20 offset 20
3 , false :
select count ( * ) from post where category_id =3 and not published
foo:
a =? or b =? :
1 , 10 :
or_sql
a in ? and b =? :
( 2 , 3 ), 10 :
in_sql
a > ? and b =? :
1 , 10 :
gt_sql
Обратим внимание на условие category_id=? and published=?, зная значения полей добавляемого поста, мы можем однозначно заполнить метки "?". Если объект:
то единственный подходящий инвалидатор из семейства будет category_id=2 and published=true и, следовательно нужно стереть соответствующие ему 3 ключа кеша. Т.е. не требуется последовательная проверка условий мы сразу получаем нужный инвалидатор по схеме и данным объекта.
Однако, что делать с более сложными условиями? В отдельных случаях кое-что можно сделать: or разложить на два инвалидатора, in развернуть в or. В остальных случаях либо придётся всё усложнить, либо сделать инвалидацию избыточной, отбросив такие условия. Приведём то, какими будут инвалидаторы для foo после таких преобразований:
foo:
a = ? :
1 : or_sql
b = ? :
10 : or_sql, gt_sql
a = ? and b = ? :
2 , 10 : in_sql
3 , 10 : in_sql
Таким образом, нам нужно для каждой модели только хранить схемы (просто списки полей), по которым при надобности мы строим инвалидаторы и запрашиваем списки ключей, которые следует стереть.
Приведу пример процедуры инвалидации для foo. Пусть мы запросили из базы объект
сменили значение a на 2 и записали обратно. При обновлении процедуру инвалидации следует прогонять и для старого, и для нового состояния объекта. Итак, инвалидаторы для старого состояния: a =1 , b =10 , a =1 and b =10 , соответствующие ключи or_sql и gt_sql (последний инвалидатор отсутсвует, можно считать пустым). Для нового состояния получаем инвалидаторы a =2 , b =10 , a =2 and b =10 , что добавляет ключ in_sql. В итоге стираются все 3 запроса.
Реализация
Я старался по-возможности абстрагироваться от языка и платформы, однако, рабочая и работающая в довольно нагруженном проекте система тоже существует. Подробнее о ней и о хитростях реализации вообще в следующей статье.
Вот уже несколько лет, как почти каждая статья о передовых подходах к кэшированию рекомендует пользоваться в продакшне следующими методиками:
Все известные мне средства для сборки проектов поддерживают добавление к именам файлов хэша их содержимого. Делается это с помощью простого конфигурационного правила (наподобие того, что показано ниже):
Столь широкая поддержка этой технологии привела к тому, что подобная практика стала чрезвычайно распространённой.
Эксперты в сфере производительности веб-проектов, кроме того, рекомендуют пользоваться методиками разделения кода. Эти методики позволяют разбивать JavaScript-код на отдельные бандлы. Такие бандлы могут быть загружены браузером параллельно, или даже лишь тогда, когда в них возникнет необходимость, по запросу браузера.
Одним из многих преимуществ разделения кода, в частности, имеющих отношение к передовым методикам кэширования, называют то, что изменения, внесённые в отдельный файл с исходным кодом, не приводят к инвалидации кэша всего бандла. Другими словами, если для npm-пакета, созданного разработчиком «X», вышло обновление безопасности, и при этом содержимое node_modules разбито на фрагменты по разработчикам, то изменить придётся только фрагмент, содержащий пакеты, созданные «X».
Проблема тут заключается в том, что если всё это скомбинировать, то подобное редко приводит к повышению эффективности долговременного кэширования данных.
На практике изменения одного из файлов исходного кода почти всегда приводят к инвалидации более чем одного выходного файла системы сборки пакетов. И это происходит именно из-за того, что к именам файлов были добавлены хэши, отражающие версии содержимого этих файлов.
Кэш браузера
Каждый раз, когда вы посещаете веб-сайт впервые, браузер локально сохраняет ресурсы веб-страницы (например, html, css, js, изображения и так далее). Это нужно для более быстрой работы и меньшего потребления трафика при следующем посещении.
Cache-Status
Каждый член списка — это одна из систем кеширования, которая обработала пакет по ходу его маршрута. Все они перечислены в порядке от бэкенда до пользователя (возможно, включая кеш самого агента пользователя, если он добавляет значение).
(два уровня кеша, где OriginCache ответил на предыдущий запрос с сохранённым значением, а CDN сохранил этот ответ и повторно использовал его для ответа на текущий запрос)
(здесь три уровня, два из которых пропустили запрос мимо кеша из-за отсутствия данного URI, а Nginx ответил из кеша)
Для каждого кеша спецификация предусматривает ряд параметров:
-
hit — параметр означает, что данный ответ пришёл из кеша, а оригинальный запрос дальше не передаётся
Согласно спецификациям, каждый кеш самостоятельно определяет, добавить ли ему поле заголовка Cache-Status . Некоторые могут добавлять его во все ответы, а другие могут делать это только тогда, когда специально настроены на это или когда запрос содержит поле заголовка, активирующее режим отладки.
Стирать предыдущие строки запрещено, чтобы можно было отладить всю цепочку кешей, обрабатывающих запрос.
Зачем это нужно?
Это поле рассказывает всю историю пакета и всех кешей, через которые он прошёл, что исключительно полезно при отладке.
Подходы к решению проблемы
Проблема, касающаяся хэшей содержимого файлов, находящихся в именах файлов, с технической точки зрения, заключается не в том, что хэши находятся в именах. Она заключается в том, что эти хэши появляются и внутри других файлов. В результате кэш этих файлов инвалидируется при изменении хэшей в именах файлов, от которых они зависят.
Решение этой проблемы заключается в том, чтобы, говоря языком вышеприведённого примера, сделать возможным импорт фрагмента vendor фрагментами dep2 и dep3 без указания информации о версии файла фрагмента vendor . При этом нужно гарантировать, чтобы загруженная версия vendor была бы правильной, принимая во внимание текущие версии dep2 и dep3 .
Как оказалось, существует несколько способов достижения этой цели:
- Карты импорта.
- Сервис-воркеры.
- Собственные скрипты для загрузки ресурсов.
▍Шаг 1
Нужно настроить бандлер так, чтобы он, при сборке проекта, не включал бы хэши содержимого файлов в их имена.
Если собрать проект, модули которого показаны на диаграмме из предыдущего примера, не включая в имена файлов хэши их содержимого, то файлы в выходной директории проекта будут выглядеть так:
Команды импорта в соответствующих модулях тоже не будут включать в себя хэши:
Кэширование в базах данных
В предыдущем разделе мы обсудили сети доставки контента (CDN) и тот факт, что они являются посредниками между клиентом и сервером. Аналогичным образом система кэширования базы данных является посредником между сервером и базой данных. Существует множество таких систем кэширования, например redis, memcache и т. д. Их работа объяснена ниже:
Уровни кеширования
Так в чём проблема? Казалось бы, существующие механизмы кеширования работают отлично, на порядок ускоряют загрузку контента пользователям и экономят кучу денег на хостинге.
Но проблема в сложности существующих технологий. Кеширование по факту происходит в несколько уровней и осуществляется по-разному для различных путей поступления запроса.
Скажем, непосредственно перед бэкендом обычно работает какой-то балансировщик нагрузки, обратный прокси или гейт для обработки API-запросов с собственным кешем. В то же время сам сервер на бэкенде тоже кеширует некоторые внутренние данные.
Дополнительно на дальнем уровне обычно работает CDN-провайдер типа Cloudflare, который раздаёт контент пользователям через свою сеть серверов. Свои кеширующие прокси могут стоять также у интернет-провайдера или в корпоративной сети.
Наконец, кешированием занимаются и многие клиенты, особенно браузеры, зачастую с несколькими уровнями кеширования у себя внутри, как сервис-воркеры, что только добавляет путаницы.
Кто-то может сказать, что чем больше разных кешей — тем лучше. Ведь даже на системном уровне есть три уровня кешей процессора, кеш в памяти, на SSD и так далее. На каждом уровне свои кеши. Всё правильно, но в веб-сервисах иногда получается так, что эти кеши находятся на одном уровне, дублируют и мешают друг другу, затрудняя настройку сбалансированной системы. Каждому кешу нужна отдельная конфигурация, а головная боль разработчика — инвалидация кеша, чтобы максимально быстро доставить новый контент к пользователю, «пробив» все уровни кешей.
Инвалидация кэша браузера
Инвалидацию кэша также называют очисткой кэша. Под очисткой подразумевается просто удаление кэша. Это делается для того, чтобы пользователю показывались именно свежие ресурсы.
Проблема, касающаяся версионирования имён файлов
Представьте, что вы создали и развернули веб-сайт. Вы воспользовались разделением кода, в результате большая часть JavaScript-кода вашего сайта загружается по запросу.
На следующей диаграмме зависимостей можно видеть точку входа кодовой базы — корневой фрагмент main , а также — три фрагмента-зависимости, загружаемых асинхронно — dep1 , dep2 и dep3 . Есть здесь и фрагмент vendor , содержащий все зависимости сайта из node_modules . Все имена файлов, в соответствии с рекомендациями по кэшированию, включают в себя хэши содержимого этих файлов.
Типичное дерево зависимостей JavaScript-модуля
Так как фрагменты dep2 и dep3 импортируют модули из фрагмента vendor , то в верхней части их кода, сгенерированного сборщиком проекта, мы, скорее всего, обнаружим команды импорта, выглядящие примерно так:
Теперь подумаем о том, что произойдёт, если изменится содержимое фрагмента vendor .
Если это произойдёт, то хэш в имени соответствующего файла тоже изменится. А так как ссылка на имя этого файла имеется в командах импорта фрагментов dep2 и dep3 , тогда нужно будет, чтобы изменились и эти команды импорта:
Однако так как эти команды импорта являются частью содержимого фрагментов dep2 и dep3 , то их изменение означает, что изменится и хэш содержимого файлов dep2 и dep3 . А значит — и имена этих файлов тоже изменятся.
Но на этом всё не заканчивается. Так как фрагмент main импортирует фрагменты dep2 и dep3 , а имена их файлов изменились, команды импорта в main тоже поменяются:
И наконец, так как содержимое файла main изменилось, имя этого файла тоже должно будет измениться.
Вот как теперь будет выглядеть диаграмма зависимостей.
Модули в дереве зависимостей, на которые повлияло единственное изменение в коде одного из листовых узлов дерева
Из этого примера видно, как небольшое изменение кода, сделанное всего лишь в одном файле, привело к инвалидации кэша 80% фрагментов бандла.
Хотя и правда то, что не все изменения приводят к столь печальным последствиям (например, инвалидация кэша листового узла приводит к инвалидации кэша всех узлов вплоть до корневого, но инвалидация кэша корневого узла не вызывает каскадной инвалидации, доходящей до листовых улов), в идеальном мире нам не приходилось бы сталкиваться с любыми ненужными инвалидациями кэша.
Это приводит нас к следующему вопросу: «Можно ли получить преимущества, даваемые иммутабельными ресурсами и долговременным кэшированием, и при этом не страдать от каскадных инвалидаций кэша?».
Проблемы с инвалидацией кеша
Инвалидация или очистка кеша — удаление всех закешированных объектов, связанных с изменениями в состоянии модели. Наиболее распространённый тип инвалидации — прямое удаление объектов. Но если мы имеем дело с пятью или десятью уровнями кеша на пути от бэкенда к конечным пользователям, то гарантировать инвалидацию не так просто.
Тут поджидает целый ряд скрытых угроз: из-за некорректной инвалидации мы можем просто поломать механизм кеширования, так что ничего не будет кешироваться вообще — и 100% запросов хлынут на бэкенд (как вариант, контент будет сохраняться только в локальном кеше, но не в CDN). Или, наоборот, ответы сохранятся там дольше, чем положено, а пользователям будет отгружаться устаревший контент. Из-за нескольких уровней кеширования может получиться так, что клиенты начнут получать смесь из новой и старой информации.
И главное, что сама конфигурация кеша из заголовка Cache-Control тоже кешируется, что может привести к большим трудностям в инвалидации.
Итак, что же предлагает Марк Ноттингем с соавторами новых спецификаций? Если кто-то не знает, Марк Ноттингем — очень авторитетный специалист, один из самых известных разработчиков инфраструктуры современного веба, входил в группу технической архитектуры W3C и в настоящее время является членом Совета по архитектуре Интернета.
Инвалидация кэша в сетях доставки контента (CDN)
Таргетированный Cache-Control
Второй предлагаемый стандарт гораздо проще. Это улучшенная версия существующего заголовка Cache-Control , который был разработан 20 лет назад и уже не удовлетворяет требованиям времени.
Все они хорошо известны разработчикам. Проблема в том, что эти инструкции «слепые» и направлены всем кешам одновременно, что в наше время не очень эффективно.
Таргетированный Cache-Control просто указывает, какой конкретно системе предназначены инструкции. Например, можно обновлять контент только для запросов во внутренний балансировщик нагрузки, но не в CDN. Или включить кеширование объекта только в CDN, но в других внешних системах. Естественно, все они должны поддерживать эти новые спецификации, чтобы выполнять таргетированные инструкции.
Небольшое отличие в синтаксисе. Здесь предлагается использовать синтаксис структурированных полей ( ; и , ), такой же, как в предыдущем поле.
(инструкция для CDN: считать ответ свежим 600 секунд, другим общим кешам — 120 секунд, а всем остальным — 60 секунд)
(разрешение на кеширование только в CDN и Squid, больше никому)
В данном виде спецификация предусматривает только одну «цель» для таргетирования — это CDN. То есть директива CDN-Cache-Control относится ко всем CDN. Но в будущем в спецификации могут добавить другие классы систем. Например, ISP-провайдеров, браузеры или корпоративные сети.
Разумеется, выполнять директиву CDN-Cache-Control может только тот CDN, который понимает эту спецификацию.
▍Шаг 3
Нужно создать JSON-объект, хранящий сведения о соответствии каждого файла, в имени которого нет хэша, каждому файлу, в имени которого хэш есть. Этот объект нужно добавить в HTML-шаблоны.
Этот JSON-объект и является картой импорта. Вот как он может выглядеть:
После этого всякий раз, когда браузер увидит команду импорта файла, находящегося по адресу, соответствующему одному из ключей карты импорта, браузер импортирует тот файл, который соответствует значению ключа.
Если воспользоваться этой картой импорта как примером, то можно выяснить, что команда импорта, ссылающаяся на файл /vendor.mjs , на самом деле выполнит запрос и загрузку файла /vendor-5e6f.mjs :
Это означает, что исходный код модулей может совершенно спокойно ссылаться на имена файлов модулей, не содержащих хэшей, а браузер всегда будет загружать файлы, имена которых содержат сведения о версиях их содержимого. А, так как хэшей нет в исходном коде модулей (они присутствуют лишь в карте импорта), то изменения этих хэшей не приведут к инвалидации модулей, отличных от тех, содержимое которых действительно изменилось.
Возможно, вы сейчас задаётесь вопросом о том, почему я создал копию каждого файла вместо того, чтобы просто файлы переименовать. Это нужно для поддержки браузеров, которые не могут работать с картами импорта. В предыдущем примере подобные браузеры увидят лишь файл /vendor.mjs и просто загрузят этот файл, поступив так, как обычно поступают, встречая подобные конструкции. В результате и оказывается, что на сервере должны существовать оба файла.
Если вы хотите увидеть карты импорта в действии, то вот — набор примеров, демонстрирующих все способы решения проблемы каскадной инвалидации кэша, показанные в этом материале. Кроме того, взгляните на конфигурацию сборки проекта, на тот случай, если вам интересно узнать о том, как я генерировал карту импорта и хэши версий для каждого файла.
Новые поля должны упростить разработку веб-приложений, а именно: упорядочить кеширование статического контента. Сейчас с этим небольшой бардак, поскольку кеширование происходит в нескольких системах на нескольких уровнях, почти как в этом ↑ комиксе. А синхронизировать все уровни непросто, ведь текущие стандарты разрабатывались в те времена, когда ещё не существовало CDN.
Владелец любого сайта с более-менее приличным трафиком знает, что кеширование кардинально улучшает производительность. Кеш и CDN стоят перед сервером и быстро отбивают большинство запросов, не трогая бэкенд. Это решает массу проблем. Во-первых, сглаживаются скачки трафика, потому что статический кеш масштабируется проще, чем сервер приложения. Во-вторых, на порядок уменьшается количество обращений к серверу, и они поступают пачками, а не по одному. Наконец, в CDN контент физически распределяется по всему миру, уменьшая задержку для пользователей из любого региона.
Кеш снимает с сервера до 99% нагрузки. В результате стоимость хостинга может упасть до смехотворной величины. Например, известный специалист по безопасности Трой Хант платит за облачный хостинг своего популярного сайта Pwned Passwords (базы утёкших паролей) меньше 3 центов в день, а у него 19 ГБ файлов и 34,4 млн запросов к API в неделю (правда, это статистика за 2018 год, с тех пор размер баз наверняка вырос). Как видно на скриншоте, из 32 408 715 запросов к API только 122 566 пошли на сервер, а остальные 99,62% получили результат из кеша.
Конечно, такой высокий результат во многом объясняется спецификой сайта. Здесь исключительно статичный контент, а большинство запросов приходит через API от приложений, куда встроена проверка паролей на предмет утечки, чтобы оперативно информировать пользователей.
Кроме количества запросов, CDN на порядок снижает трафик с сервера. В данном случае общий трафик за неделю составил 477,63 ГБ, в том числе оплаченный трафик с облака — всего 945,96 МБ. Теперь понятно, почему хостинг обходится ему так дёшево.
Подводные камни
Как у любого решения в разработке, кэширование — не серебряная пуля и имеет свои недостатки. Несколько моментов, которые стоит держать в уме при использовании кэша:
- приложение должно уметь работать без кэша. Кэширующий сервер упал или недоступен? Пользователь все равно должен получать все данные просто с небольшой задержкой. Завязывать какую-то логику продукта на кэш (например, хранить данные аналитики только в кэше) — нельзя, потому что это ненадежное хранилище.
- с введением нового звена в архитектуру всегда следует усложнение разработки и поддержки продукта. Проверка и запись значений в кэше — это дополнительная логика в коде, которая требует дополнительного времени на тестирование и исправление потенциальных ошибок.
- сколько времени должно храниться значение в кэше? Что делать, если значение невалидно, так как пользователь открыл новую сделку или получил прибыль? Эти вопросы будут возникать постоянно, и в каждом проекте ответы будут уникальными.
Принятие индустрией
Черновики этих стандартов были опубликованы только в июле и августе 2021 года, они ещё совсем свежие. В ближайшее время посмотрим, как индустрия их примет. Пока есть только первые примеры поддержки Cache-Status .
Кроме того, Cloudflare и Akamai поддерживают общий для них CDN-Cache-Control , а также отдельные Akamai-Cache-Control и Cloudflare-CDN-Cache-Control . То есть это уже работает.
Прежде чем мы начнем говорить о инвалидации кэша, давайте посмотрим, что такое кэш на самом деле. Википедия говорит, что кэш — это просто промежуточный буфер с быстрым доступом к нему, содержащий информацию, которая может быть запрошена с наибольшей вероятностью.
В этой статье мы поговорим о трех наиболее часто используемых типах кэша:
- Кэш браузера
- Кэш сетей доставки контента (CDN — Content Delivery Network)
- Кэширование в базах данных
Кэширование
Представим, что нужно записать количество сделок пользователя в кэш. Запишем, что у пользователя с ID 33 имеется 5 сделок. Используем обычную команду set :
Данные записаны. Однако они будут храниться вечно до следующей перезагрузки сервера или пока не будут удалены вручную. Одно из основных свойств кэша — это то, что он хранится короткий промежуток времени. Данных может быть много, а ресурсы серверов не бесконечны. К счастью в Redis можно указать время жизни ключа (время экспирации), по истечении которого ключ будет удален. Для этого достаточно добавить префикс ex количество_секунд к команде set :
Проверить, через сколько ключ удалится можно командой ttl :
В данном случае ключ user:33:deals_count исчезнет через 115 секунд.
Если попытаться получить значение спустя это время, то вернется пустой ответ:
Время жизни можно задавать не только в секундах, но и в миллисекундах с помощью префикса px количество_миллисекунд :
Проверка времени жизни осуществляется командой pttl :
Вывод выше показывает, что ключ user:33:deals_count исчезнет через 7484 миллисекунд (~7.4 секунд).
Читайте также: