Как я должен обслуживать ZIPped веб-страницы?

Question

Справочная информация:
Наше программное обеспечение генерирует отчеты для клиентов в обычных подозрительных форматах (HTML, PDF и т. Д.), И каждый отчет может содержать диаграммы и другую графику, уникальную для этого отчета. Для PDF-файлов все хранится в одном месте - сам PDF-файл. HTML сложнее, так как отчет - это сумма более одного файла. Файлы доступны через HTTP через Tomcat.

Проблема:
Я действительно хочу иметь аккуратную среду и обернуть отчеты HTML в один файл. Есть MTHML, Data URI, несколько форматов для рассмотрения. Этот превосходный вопрос утверждает, что, учитывая отсутствие поддержки кросс-броузера для этих форматов, ZIP является изящным решением. Это привлекательно для меня, поскольку я также могу предложить zip-файл для загрузки в качестве опции «HTML-отчет, который вы можете отправить по электронной почте». (Раньше пользователи жаловались на то, что теряли графику, когда начинали отправлять отчеты в формате HTML)

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

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

Кто-нибудь может подсказать, хорошо это или плохо, и предложить альтернативное решение?

Изменить для получения дополнительной информации!
Отчеты должны сохраняться на сервере. Наши клиенты являются пользователями сайтов, и видимость одного отчета может быть такой же широкой, как и у всех на сайте. Процесс создания предполагает, что пользователь выбирает критерии для отчета и отправляет его для создания на сервер. Данные извлекаются из базы данных и создается документ. Заполнитель записи попадает в базу данных, а сами документы хранятся где-то на файловом сервере. Это часть «документов на файловом сервере», которую я бы хотел привести в порядок - архивирование также означает меньшее использование дискового пространства !. После создания отчета он доступен всем, кто его видит.

Answer 1

Как только отчет создан, он доступно каждому, кто может его увидеть.

это довольно красноречиво - это означает, что отчеты являются разделяемыми, и вы также хотели бы «кэшировать» отчеты, чтобы их не приходилось регенерировать.

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

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

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

Answer 2

Я бы подумал, что план будет заключаться в том, чтобы zip-файл заканчивался на клиенте , а не на сервере.

Не зная о вашей архитектуре, я бы предположил такой подход:

• Отчет о пользовательских запросах
• Сервер отображает отчет в формате HTML
• Пользователь, возможно, подправляет некоторые параметры, повторяет запрос
• Сервер отображает отчет в формате HTML (повторяйте, пока пользователь не будет доволен)
• В каждом отчете HTML есть ссылка "скачать как почтовый индекс"
• Пользователь нажимает на ссылку
• Сервер регенерирует отчет, сохраняет его в zip-файле и передает его пользователю
• Пользователь сохраняет где-нибудь zip-файл, пересылает его по электронной почте и т. Д. - сервер вообще не задействован

Конечно, это зависит от возможности повторного запуска отчета для создания zip-файла. Вы могли бы генерировать zip-файл каждый раз, когда генерируете какой-то HTML, но это расточительно, если вам не нужно , чтобы это сделать, требуется очистка и т.д.

Возможно, я вас неправильно понял ... если это не звучит уместно, не могли бы вы обновить свой вопрос?

РЕДАКТИРОВАТЬ: Хорошо, увидев обновление вашего вопроса, у меня будет соблазн сохранить файлы для каждого отчета в отдельном каталоге (например, используя GUID в качестве имени каталога). Многие файловые системы поддерживают сжатие на уровне файловой системы, поэтому «преждевременное сжатие», вероятно, не сэкономит много места на диске и затруднит извлечение отдельных файлов. Затем, если пользователь запрашивает zip-файл, вам просто нужно создать zip-файл в этот момент, возможно, просто в памяти, перед тем, как его обслуживать.

Answer 3

Вам не нужно физически создавать zip-файлы в файловой системе. Нет ничего плохого в создании почтовых индексов в памяти, потоковой передаче их в браузер и разрешении GC освободить память, занятую временным почтовым индексом. Это, конечно, создает проблемы, поскольку может быть неэффективно постоянно воссоздавать zip каждый раз, когда делается запрос. Однако судите об этих вещах в соответствии с вашими потребностями и т. Д.