Пользовательский обработчик изображений: стратегия кэширования

Question

Сценарий

Я создаю пользовательскую CMS для коммуникационного приложения. Пользователи могут загружать изображения на сервер, а затем ссылаться на них в постах, которые они пишут, используя уценку. Изображения хранятся в базе данных и имеют URL-адрес вида images/{id}. Пользовательский обработчик изображений извлекает их и устанавливает заголовок с истекшим сроком в будущем, чтобы они не загружались снова и снова. Хранение изображений в файловой системе не вариант для клиента.

Записи хранятся в базе данных как уценка и как HTML для производительности.

Markdown

###Header
Lorem Ipsum dolor sit amet.  ![funny cat](images/25)

HTML

<h3>Header</h3>
<p>
  Lorem Ipsum dolor sit amet. <img alt="funny cat" src="images/25" />
</p>

Проблема

Эти изображения также доступны для редактирования. С точки зрения кэширования это представляет проблему. Когда изображение редактируется, мне нужно убедиться, что браузер получает последнюю версию. Я нашел следующие решения, которых мне все не хватало.

Возможные решения

Поле версии

Сохранить поле версии с изображением. Увеличивайте его, когда изображение редактируется, создавая URL вида images/{id}/version/{version}.

Это хорошо, если URL-адреса изображений всегда генерируются из базы данных. Тем не менее, я храню URL-адреса в сообщениях в виде текста, и для этих запросов придется предварительно обрабатывать, возможно, большие фрагменты текста. Кроме того, связывание изображения будет проблематичным, поскольку URL-адрес становится устаревшим после редактирования изображения. Это, вероятно, не очень хорошая идея.

Новый URL

Когда изображение редактируется, сохраните его как новую запись в базе данных.

Это означает, что нет поддержки версии, но старые ссылки и старые сообщения страдают от тех же проблем. Они никогда не обновляются. Производительность была бы хорошей, но проблема осталась.

304 - не изменено

Сохранение последнего отредактированного поля для каждого изображения. Когда приходит условный запрос, возвращается статус http 304 - Не изменено, что уменьшает использование полосы пропускания.

Кажется, это лучшее решение, которое у меня есть. Изображение кэшируется, если не отредактировано, но я никогда не использовал этот подход раньше. Если на странице 50 изображений, к серверу еще 50 запросов. Пропускная способность будет уменьшена, но задержка останется. Стоит ли такой подход такой стоимости?

Вопрос

У меня очень мало опыта в этой области, и я надеюсь, что у всех вас есть больше. Являются ли какие-либо из перечисленных решений жизнеспособными? Если да, какой у тебя опыт с ними? Если нет, то какой подход лучше?

Answer 1

Как вы сказали, условное GET - лучший вариант, так как вам нужно проверить только один заголовок запроса (If-None-Match или If-Modified-Since) и отправить обратно соответствующий код состояния (200 или 304). ) и заголовок (E-Tag или Last-Modified). Тогда браузер будет иметь дело с кешем изображений.

Кроме того, в зависимости от вашей серверной инфраструктуры, если вы храните ваши изображения в базе данных, вы можете кэшировать их в первый раз, когда они вам понадобятся (в течение ограниченного времени, поэтому вы не занимаете всю память сервера). Это помогает, когда вам нужно читать одно и то же изображение повторно, сохраняя запросы к базе данных. Конечно, вам нужно удалить свое изображение из кэша сервера, если вы их редактируете.

РЕДАКТИРОВАТЬ: спасибо, что приняли ответ. Если вам это нужно, вот хорошая пояснительная ссылка: Условное получение HTTP для хакеров RSS .

Answer 2

Поместите изображения на диск и пусть ваш веб-сервер справится с этим.

Файл может иметь то же имя (и, следовательно, URL), и веб-сервер может работать с измененными заголовками из браузеров. Также браузеры могут быть немного счастливее с URL-адресами с известными расширениями.

Размещение изображений в базе данных и их передача с помощью сценария, как правило, не очень хорошая идея. Просто есть ссылка на URL в базе данных.