引用一些着名的词:
"程序员......往往会以一种可以理解但又灾难性的倾向于避免他们工作中的复杂性和独创性.禁止设计比计划更大的任何东西,他们通过使该计划错综复杂来挑战他们的专业技能来做出回应."
在解决工作中一些平凡的问题时,我提出了这个想法,我不太清楚如何解决.我知道我不会实现这个,但我很好奇最好的解决方案是什么.:)
假设你有一个包含JPG文件和一些奇怪的SWF文件的大集合."大"我的意思是"几千".每个JPG文件大约200KB,SWF最大可达几MB.每天都有一些新的JPG文件.因此,所有东西的总大小约为1 GB,并且缓慢但稳定地增加.很少更改或删除文件.
用户可以在网页上单独查看每个文件.但是,也希望允许他们一次下载一大堆.这些文件附加了一些元数据(日期,类别等),用户可以通过这些元数据过滤集合.
最终的实现是允许用户指定一些过滤条件,然后将相应的文件下载为单个ZIP文件.
由于标准量足够大,我无法预先生成所有可能的ZIP文件,因此必须即时执行.另一个问题是下载可能非常大,对于连接速度慢的用户来说,很可能需要一个小时或更长时间.因此,支持"简历"是必须的.
然而,在光明的一面,ZIP不需要压缩任何东西 - 无论如何文件大多是JPEG.因此,整个过程不应该比简单的文件下载更耗费CPU.
因此我发现的问题是:
你会如何实现这个？PHP完全可以胜任这项任务吗？
到目前为止,已有两个人建议将所请求的ZIP文件存储在一个临时文件夹中,并从那里作为常用文件提供服务.虽然这确实是一个明显的解决方案,但有几个实际考虑因素使这种做法变得不可行.
ZIP文件通常非常大,从几十兆到几千兆字节.用户请求"所有内容"也是完全正常的,这意味着ZIP文件的大小将超过千兆字节.此外,还有许多可能的过滤器组合,其中许多可能由用户选择.
因此,ZIP文件的生成速度非常慢(由于数据量和磁盘速度很快),并且会多次包含整个集合.如果没有一些超级昂贵的SCSI RAID阵列,我不知道这个解决方案是如何工作的.
这可能是你需要的:http: //pablotron.org/software/zipstream-php/
此lib允许您构建动态流zip文件而无需交换到磁盘.
使用例如PhpConcept Library Zip库。
恢复必须得到您的网络服务器的支持，除非您不直接访问 zip 文件。如果您有一个 php 脚本作为中介，那么请注意发送正确的标头以支持恢复。
创建文件的脚本不应该超时，只是确保用户不能一次选择数千个文件。并保留一些内容来删除“旧的 zip 文件”，并注意某些恶意用户不会通过请求许多不同的文件集合来耗尽您的磁盘空间。