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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

EDIT: Хорошо, увидев обновление вашего вопроса, у меня возникнет соблазн хранить файлы для каждого отчета в отдельном каталоге (например, с использованием GUID в качестве имени каталога). Многие файловые системы поддерживают сжатие на уровне файловой системы, поэтому «преждевременная задержка», вероятно, не сэкономит много места на диске и сделает извлечение отдельных файлов более сложным. Затем, если пользователь запрашивает zip, вам просто нужно создать zip-файл в этой точке, возможно, только в памяти, перед тем, как подавать его.

Answer 2

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

Answer 3

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

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

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

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

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