Запрос проходит через несколько слоёв кэширования, каждый из которых находится ближе к пользователю и работает быстрее, но хранит меньше данных. Идея состоит в том, чтобы ответить как можно дальше (ближе к клиенту) и переходить к источнику только когда никакой из верхних слоёв не может предоставить ответ.
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag; ресурсы часто получают длительные TTL (дни–год) с хешированными именами файлов.for each layer outward → inward:
if layer has fresh copy → return it (stop here) // a hit; cheapest possible
else → ask the next layer in // a miss; falls through
origin (app + DB) → does the real work, fills caches on the way back out
Каждый слой обменивает свежесть на скорость: внешние слои работают быстрее, но с большей вероятностью содержат устаревшие данные, поэтому используйте длительные TTL + хеширование содержимого для действительно статических объектов и короткие TTL + инвалидацию для динамических.
Большая часть снижения задержки и нагрузки в веб-стеке достигается благодаря кэшированию на правильном уровне. Знание того, какие данные хранит каждый слой и его типичный TTL, позволяет разместить кэш там, где он действительно помогает, избежать подачи устаревших данных и понять, почему изменение не появилось (какой слой всё ещё выдаёт старую копию).
Библиотека вопросов для IT-собеседований с подробными ответами — от Junior до Senior.
Поддержать