Архитектура для высокопроизводительного кэширования файлов изображений, созданных на лету

Question

Я разрабатываю приложение, которое должно обслуживать файлы растровых изображений с различными уровнями масштабирования векторного изображения, хранящегося на сервере.Представьте себе векторизацию данных улиц и зданий и создание на лету плитки PNG для сервиса, подобного Google-картам, в ответ на запрос клиента об определенном уровне масштабирования и координатах.

В моем случаебазовые векторные данные изменяются довольно часто, а уровни масштабирования увеличиваются с гораздо меньшим шагом, чем, например, дюжина или около того фиксированных шагов масштабирования в Картах Google.Следовательно, для меня нецелесообразно предварительно рассчитать все возможные листы и загрузить их на высокопроизводительный статический медиасервер.

Существует ли элегантный способ получить первый запрос на получение определенной плитки отприложение, которое его генерирует, и все последующие запросы на обслуживание со статического медиа-сервера?

Предположим, что как только я сгенерирую плитку на сервере приложений, я сразу же смогу сделать ее доступной на статическом медиа-сервере.

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

Так что я ищу другие идеи.Например, есть ли способ настроить веб-сервер, чтобы он пытался использовать высокопроизводительную статическую обработку файлов, и если файл не существует, то вместо того, чтобы возвращать 404?, Можно вернуться к вызову приложения?

Answer 1

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

В NginX есть try_files вариант.Это берет набор URI и, как вы ожидаете, пробует каждый из них, пока не найдет ответ.Если первый набор завершается неудачно, но более поздний возвращает OK и данные (и, пока он там есть, также создает файл, который будет соответствовать первому пути файла попытки), тогда следующий запрос будет закорочен.

try_files $uri $uri/ /makeCacheFile.php?q=$uri&$args;

В Apache что-то подобное будет работать примерно так же с mod_rewrite

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.+)$ /makeCacheFile.php?q=$1 [L,QSA]

Здесь мы проверяем, подается ли конкретный файл для запроса, и если нет, передаем URL-адресскрипт, который может продолжать генерировать его.