какая разница между кешем и усилителем http-кеш «обратный прокси»
У меня возникли трудности с пониманием разницы между обычным кэшем «память, файл, дБ и т. д.» и http-кэшированием «обратный прокси».
Пример.
допустим, у меня есть страница, разделенная на 3 части.
- фильмы
- игры
- Программы
и когда я получаю эти части из базы данных, я кеширую каждую часть в своем собственном ключе & когда новые данные вводятся в любую из этих частей, я очищаю кэш и переделываю его, включая новые данные, так что теперь каждая часть будет обновляться только при добавлении чего-то нового.
с другой стороны, кеширование http есть что-то назвать ESI который вы можете включить частичные страницы, которые имеют другой срок службы кэша от главной страницы, что идеально, но
зачем мне его использовать?
или в чем преимущество перед первым методом?
редактировать
- это намного тоньше того, что было после, но все же, зачем вам использовать / продолжать использовать обратный прокси-сервер по сравнению с приведенным ниже?
https://laracasts.com/series/russian-doll-caching-in-laravel
https://www.reddit.com/r/laravel/comments/3b16wr/caching_final_html_from_view/
https://github.com/laracasts/matryoshka
Решение
Кэш обратного прокси имеет несколько преимуществ:
- Запросы, обслуживаемые прокси-сервером, никогда не попадают на ваш веб-сервер. Это обычно
дешевле / проще масштабировать прокси-серверы (например, используя
коммерческие провайдеры, такие как Akamai), чем масштабировать ваши
Веб-сервер (ы). - Это означает, что вы можете пережить всплески трафика и отрицание
сервис атак с гораздо меньшим стрессом. - Это также означает, что вы можете служить
трафик, который не близко к вашему исходному веб-серверу, намного быстрее — если
Ваш сайт обслуживает глобальную аудиторию, задержка может оказать большое влияние на
Ваше предполагаемое время ответа. - Вы также можете отключить ваш веб-сервер, например для обновлений, не затрагивая ваших конечных пользователей.
Недостатки обратного прокси-кэширования:
- Это дополнительный уровень архитектуры, который обеспечивает сложность, обслуживание, администрирование и т. Д.
- Это также может потребовать дополнительных затрат (большинство сайтов имеют отдельную инфраструктуру для обратных прокси-серверов или используют коммерческий поставщик CDN).
- Проект вашего решения должен управлять аннулированием кэша между несколькими уровнями — это может легко стать сложным и подверженным ошибкам.
- Это, в свою очередь, означает, что отладка и тестирование решения могут быть очень сложными. Если команда QA сообщает о неверной странице, вам необходимо выяснить, откуда был доставлен элемент — обратный прокси-сервер, кэш приложения, база данных?
Другие решения
Других решений пока нет …