Обратный прокси-сервер nginx, когда использовать кеш против хранилища?

Я нахожусь в процессе реструктуризации веб-стека моего проекта в: nginx -> haproxy -> много (apache / passenger rails) экземпляров

Некоторые из целей включают в себя:

• одно место для кэширования страниц (в настоящее время выполняется через рельсы на каждой машине apache)
• быстрее статический контент
• удалить ssl из внутреннего конвейера
• протоколирование ip (ранее потеряно из-за запуска haproxy в режиме tcp)

Ресурсы image / stylesheet / javascript кэшируются в кэше с соответствующими заголовками. Наше кэширование страниц основано на внутренних параметрах и не должно реагировать на типичные элементы управления кэшем. Для достижения этих целей наш конфиг выглядит примерно так

server {

    ...

    location /really_slow_dynamic_content/ {
        root /var/www/tmp;
        error_page 404 = @fetch;
    }

    location @fetch {
        internal;
        proxy_pass   haproxy_ip;
        proxy_store  /var/www/tmp${uri}_cache.html;
        proxy_store_access  user:rw  group:rw  all:r;
    }

    location /assets/ {
        proxy_pass   haproxy_ip;
        proxy_cache  assets;
    }

    location / {
        proxy_pass   haproxy_ip;
    }
}

Я не очень большой системный администратор, и я знаю, что есть много альтернатив / настроек / дополнений, которые могут быть полезны. Я также не совсем понимаю разницу между proxy_cache и proxy_store. Итак, на мой актуальный вопрос ...

Пока мы не переместим ресурсы на компьютер nginx, имеет ли смысл использовать proxy_cache для ресурсов и proxy_store для медленного динамического контента?

Кроме того, если есть другие соображения или программное обеспечение, которое я должен рассмотреть, я хотел бы услышать о них. Спасибо!

После публикации этого вопроса я понял, что первоначальная конфигурация, которую я использовал, вообще не использует хранилище, и что error_page и внутренние настройки из (полу?) Официального вики-примера не были полностью необязательными (конфигурация обновлена ​​здесь, так как кажется, что работает, и рабочий конфиг кажется лучшим наследием для этого вопроса). Таким образом, использование магазина для медленного создания (и редко обновляемого) полных страниц, и фактический кэш для изображений, javascript и тому подобного, похоже, работает для нас довольно хорошо. Я приму один ответ, так как он, по крайней мере, дал мне возможность отследить мою проблему, но я до сих пор не понимаю, использую ли я две директивы так, как они были предназначены или нет (ну, по крайней мере, не в отношении магазина, кэш кажется немного более очевидным).

Если память обслуживает меня правильно, proxy_store хранит двоичное представление запроса на элемент, тогда как proxy_cache сохраняет кэшированную копию элемента в его базовой форме.

proxy_cache на самом деле является надлежащим механизмом кэширования с несколькими уровнями и подходит для хранения контента с нескольких сайтов с использованием одних и тех же ключей.

Я лично использую proxy_cache для хранения более 2 миллиардов изображений продуктов на каждом из наших статических контент-серверов.

proxy_store используется для создания зеркала объектов «по запросу». Он помещает элементы в тот же путь, по которому данный элемент существует в бэкэнде.

В случае медленного динамического содержимого, proxy_cache является более подходящим, поскольку он поддерживает истечение срока действия кэша.

Примером, где proxy_store является более полезным, может быть зеркало rpm-файлов, в которых никогда не требуется истечение срока действия одного имени файла / версии .